Pro Base64 Encoder & Decoder
Convert text and images locally: UTF-8–safe text encoding, robust decoding with optional Data URI stripping, and image uploads with live Data URI preview. No sticky chrome, no forced scrolling—everything stays in the document flow.
Input
Choose encode or decode. All processing stays in your browser.
Output
Monospace string area—copy or download as .txt.
Status: Waiting for input
Image to Base64 (Data URI)
PNG, JPG, SVG, or WebP. Preview the raster/vector output, copy the full Data URI, or download the original bytes as a file.
Drop an image here
or click to browse · PNG, JPG, SVG, WebP
Preview
No image loaded yet.
No file selected
Knowledge base
What is Base64 encoding and when should you use it?
Base64 is a binary-to-text encoding scheme. It represents arbitrary bytes using a small alphabet of 64 printable characters (A–Z, a–z, 0–9, +, /) plus padding = when the byte length is not divisible by three. The goal is not secrecy—it is survivability across systems that only tolerate text: email bodies, JSON string fields, data URLs inside HTML/CSS, PEM certificates, and serialization layers that cannot embed raw NUL bytes or control characters safely.
Reach for Base64 when you need a deterministic byte payload to travel through a text-only channel, when you want a single self-contained asset inline (for example a favicon or 1×1 tracking pixel), or when you are debugging transports and want to eyeball bytes without a hex editor. Avoid it when HTTP caching, byte-range requests, or CDN optimization matter more than convenience—normal file URLs almost always win for larger media.
Benefits of embedding small images as Base64 in CSS/HTML
Inlining tiny graphics removes extra round trips: the browser does not open another TCP connection or contend with queueing on HTTP/1.1-style pages, which improves time-to-first-byte for decorative sprites, bullet icons, and micro-ornaments. Design tokens shipped as Data URIs inside CSS also travel with the stylesheet, which can be useful for email templates, offline exports, and storybook-style component playgrounds where a single file must render identically everywhere.
For critical rendering paths, a small Data URI can double as a low-quality image placeholder while the full-resolution asset lazy-loads, reducing layout shift when implemented thoughtfully. The trade is always size: the same PNG expressed as Base64 is heavier on the wire than binary, so treat this pattern as a precision tool for assets measured in kilobytes—not megabytes.
Base64 security: Is it encryption or just encoding?
Base64 is not encryption, signing, or authentication. Anyone can decode standard Base64 instantly—there is no key material. If you need confidentiality, pair real cryptography (for example AES-GCM with proper key management or libsodium sealed boxes) with authenticated transport such as TLS. Wrapping secrets in Base64 without encryption is security theater: it only obscures data from casual glances, not from attackers.
From a defensive standpoint, treat decoded Base64 as untrusted input. Malicious payloads may become executable when interpreted (SVG with scripts, polyglot files, or unusually large strings that exhaust memory). Validate sizes, strip dangerous namespaces when appropriate, and never pipe decoded bytes into eval or dynamic code execution paths.
Frequently asked questions
Why does Base64 increase size by about 33%?
Base64 maps every 3 bytes of binary input into 4 printable ASCII characters (6 bits per character × 4 = 24 bits). That expansion is structural: you trade compact binary representation for a charset that survives text channels. Whitespace, line breaks in PEM-style wrapping, and Data URI prefixes add even more characters on top of the raw payload.
How does Base64 handle binary data versus Unicode text?
Base64 itself is byte-oriented: it encodes raw bytes, not “letters.” For Unicode strings you must first convert text to bytes (UTF-8 is the web default) before calling btoa. Decoding yields bytes that must be interpreted as UTF-8 (or another encoding) to restore the original string. Treating decoded bytes as ISO-8859-1 text is a common source of mojibake.
Do all modern browsers support atob, btoa, and Data URIs?
Current evergreen browsers support window.atob / window.btoa for binary strings and <img src="data:..."> for image Data URIs, with practical limits on URI length and memory for very large assets. Very old engines lack btoa for strings with code points outside Latin-1 unless you UTF-8 encode first. For massive files, prefer Blob URLs or normal HTTP caching instead of inlining.
When should I avoid inlining images as Base64?
Skip Base64 for large photos, hero backgrounds, or assets that should be cached independently: you lose granular HTTP caching, duplicate bytes when the same image appears on multiple pages, and can block first paint if the inline string is huge. Reserve Data URIs for tiny icons, critical above-the-fold placeholders, or tooling—not for big photographic content.
More tools
Pair payload cleanup with metadata workflows on the same static layout system.