Base64 Encoder / Decoder
Encode text or files to Base64 and decode Base64 back, with strict RFC 4648 validation: canonical-form checking, alphabet detection, verified file signatures and a hex view. Everything runs in your browser.
File to Base64
Drag a file here or browse
Any file type · up to 50 MB · converted locally in bounded chunks, the file never leaves your browser
Base64 to file
Paste Base64 or a full data: URI. The decoded size is estimated before anything runs, the type is verified against the actual bytes, and you can download the result.
Strict Base64 validator (RFC 4648)
Checks alphabet, padding, length and canonical pad bits. Valid, canonical, normalized and malformed are four different verdicts, and this validator tells you which one you have.
Base64 ↔ hex
Bounded at 2 MB of data per direction. Bytes with no valid UTF-8 meaning are fine here: hex is the binary-safe view.
How Base64 works: 3 bytes in, 4 characters out
A Base64 encoder reads binary data 3 bytes (24 bits) at a time, splits those bits into four 6-bit numbers, and maps each number to one of 64 printable characters: A to Z, a to z, 0 to 9, then + and /. Because every character carries only 6 of its 8 bits of storage, the output is 4 characters for every 3 input bytes, about 33 percent larger than the original. Here is the full journey for the three characters "Hi!":
| Step | Encoding "Hi!" |
|---|---|
| Input bytes | H = 72, i = 105, ! = 33 |
| As 8-bit binary | 01001000 01101001 00100001 |
| Regrouped into 6-bit | 010010 000110 100100 100001 |
| As numbers 0 to 63 | 18, 6, 36, 33 |
| Base64 output | S G k h → "SGkh" |
When the input is not a multiple of 3 bytes, the encoder pads the final block with one or two = characters, and RFC 4648 requires the leftover bits of the last data character to be zero. That last rule is what most online converters skip: they will happily accept Zh==, which no conforming encoder ever produces, without telling you. The Validate tab here checks it, explains it, and offers the canonical form.
Decoded bytes are the truth, text is a view
Base64 often carries data that is not text at all. This workbench treats the decoded bytes as the canonical result: if they are not valid UTF-8, the text pane shows a clearly labeled lossy preview with replacement characters, but re-encoding that unchanged preview reproduces the original bytes exactly instead of destroying them. The Hex tab shows every byte faithfully, and the File tab verifies what the bytes actually are, with the declared MIME type and the detected signature shown separately and mismatches called out.
Image to Base64: when inlining helps and when it hurts
Converting an image to Base64 and inlining it as a data URI removes an HTTP request: the bytes arrive with the document itself. That is genuinely useful for tiny assets: a 1 KB icon, a logo in an HTML email where clients block external images. For those cases, the File tab hands you a ready HTML img tag or CSS background-image rule. For anything bigger, inlining backfires: the Base64 form is 33 percent heavier, cannot be cached separately, and is invisible to lazy loading, which is why the embed snippets disappear above 2 MB here instead of encouraging a mistake.
Base64 encoding and decoding FAQ
What is Base64 encoding?
Base64 is a way to represent binary data using 64 printable characters: A-Z, a-z, 0-9, plus + and /. Every 3 bytes of input become 4 characters of output, which lets images, files and other binary data travel through systems that only handle text, such as JSON, XML, email bodies and data URIs. It is an encoding, not a compression and not an encryption.
What does "non-canonical Base64" mean?
When the input length is not a multiple of 3, the final Base64 character has spare bits, and RFC 4648 requires a conforming encoder to set them to zero. If they are not zero, several different strings decode to the same bytes: Zh== and Zg== both decode to "f", but only Zg== is canonical. That ambiguity has caused real security bugs in systems that compare encoded strings instead of decoded bytes. This tool flags non-canonical input, shows the canonical form, and can normalize it in one click.
How do I Base64 encode text with Unicode characters?
The classic JavaScript btoa function fails on characters outside Latin-1, which is why naive encoders break on emoji and accented letters. This Base64 encoder first converts your text to UTF-8 bytes with TextEncoder, then encodes those bytes, so accented words, Chinese characters and emoji all round-trip correctly. The stats below the panes count real graphemes and code points, not UTF-16 units, so one emoji is one character.
Is Base64 encryption? Is it secure?
No. Base64 is a reversible transformation with no key: anyone can decode it instantly, including this page. Never treat Base64 as protection for passwords, tokens or personal data. If you need confidentiality, use real encryption such as AES or TLS, and use Base64 only to move the encrypted bytes through text-based systems.
What is URL-safe Base64 and why does mixing alphabets matter?
Standard Base64 uses + and /, which clash with URLs and file names, so RFC 4648 defines a URL-safe variant using - and _ instead, usually without = padding. JWTs and many web APIs use it. A single payload should use one alphabet: input containing both + / and - _ was never produced by one conforming encoder and usually means corruption or two payloads pasted together, which is why this tool flags mixed alphabets instead of silently accepting them.
How large a file can I convert, and why is there a limit?
Up to 50 MB. The conversion runs in bounded chunks with a real cancel button, and large results are offered as a download instead of being rendered into the page, but browser memory is still finite: Base64 output is 33 percent larger than the input, and a tab, especially on mobile, will crash if a converter pretends there is no ceiling. The estimated output size is shown before encoding starts. For larger files, use a command-line tool like base64 or certutil.
How does the tool know what file type my Base64 decodes to?
Two sources, kept separate on purpose: what the data URI header declares, and what the decoded bytes actually look like, based on file signatures including PNG, JPEG, WebP, PDF, ZIP and the ISO media brands that distinguish MP4 from HEIC from AVIF. If they disagree, you get a warning and the real signature wins for the preview and file extension, because a payload claiming to be an image while containing something else deserves suspicion, not trust.
More free tools: Base64 Validator · Base64 to Text · Image to Base64 · Base64 to Image · JSON Formatter