Base64 Encoder / Decoder

This page converts between text and Base64 in both directions, and it does the work in the tab: the bytes are produced by the browser's TextEncoder, the Base64 alphabet is applied by hand, and decoding runs through a strict UTF-8 decoder. Nothing is uploaded. The sections below cover the four things that actually go wrong with Base64 in production, because "Base64 is just text" is exactly the belief that causes them.

Padding: optional, and the length tells you if the data is broken

Base64 takes three bytes and writes four characters. When the input is not a multiple of three the final group is short, and = is appended to bring the group back up to four characters. Those equals signs carry no data at all — they only record how many bytes the last group holds. One = means the final group was two bytes, two of them mean one byte, and no padding means the input was a clean multiple of three.

Because the padding is not data, a decoder can accept a string with it or without it, and this tool accepts both. What a decoder must never accept is a length that leaves a remainder of one when divided by four: that always means characters are missing, and reconstructing the last byte from one leftover character is impossible. If you see an error mentioning a truncated group, you almost certainly lost a character from the end. The URL-safe variant used by JSON Web Tokens usually strips padding on purpose, so unpadded input is normal, not corrupt.

Standard Base64, base64url, and the two characters that differ

The two alphabets are identical except for the last two codes. Standard Base64 uses + and /; base64url replaces them with - and _. That matters because + means a space in a form body and / ends a path segment, so a standard-Base64 value dropped into a URL gets corrupted unless it is percent-encoded. JWTs and many cookie values therefore use base64url and drop the padding, giving a string that is safe to concatenate into a URL with no escaping.

Feeding one alphabet to a decoder expecting the other fails in a specific way: the decoder reaches a - or _ and stops. This tool reports the position of the first character it cannot accept instead of returning silently wrong bytes, and that is the fastest way to tell which variant you are holding. If a string contains - or _, tick the URL-safe box; if it contains + or /, leave it off.

Base64 is not text, and it grows the payload by a third

Every three bytes become four characters, so Base64 costs about thirty-three percent more space — and the alphabet contains only ASCII, which is why it survives round trips through systems that mangle binary. The trap is on the text side. The old browser function btoa accepts only Latin-1 and throws on any character above code point 255, which is why naive encoders break the moment someone types an emoji. This page sidesteps that entirely: it encodes the string to UTF-8 bytes with TextEncoder and then encodes those bytes, so a single emoji correctly becomes four bytes and therefore a longer Base64 string than a plain letter.

Decoding has the mirror-image problem. A Base64 payload can hold any bytes at all, and only some of them form valid UTF-8 text. Decoders that guess produce the replacement character or, worse, silently drop bytes. Here the bytes are run through a strict decoder set to fail rather than substitute, and when it fails the payload is treated as binary: you get a hex dump and a Download .bin button so the original bytes are preserved. If you needed the file, not the text, that is the result you want.

Data URLs: the MIME prefix is part of the format

A data URL looks like data:image/png;base64,iVBOR…. Everything up to the first comma is metadata — the MIME type and the word base64 — and must be removed before the payload is decoded. This page detects data URLs and reads the declared type directly; for a bare Base64 image it falls back to the file signature in the first bytes, checking for the PNG, JPEG, GIF and WebP magic numbers. The preview is built from the decoded bytes with a blob URL, so the image is rendered from your paste and never fetched.

How to verify that nothing is uploaded

Open the developer tools, go to the Network panel and clear it. Decode something here and watch for a request carrying your input; there is none. Then disconnect from the network and decode again — it still works, because the whole conversion lives in the page. The only third-party script is the ad tag, which cannot see the workbench. The privacy policy lists every script and what it can read.

Is Base64 encryption? Is my data safe to paste?

Base64 is not encryption. It is a reversible way to carry arbitrary bytes inside text, and anyone can decode it without a key. Treat a Base64 blob as plain data. Because of that, doing the decode in the page matters: decoding a token or a config blob that contains a credential would leak it to any site that processed it on a server, and this one never does.

Why does decoding sometimes show a hex dump instead of text?

Because not every Base64 payload decodes to text. Images, zipped files, PDFs and encrypted blobs are all valid Base64 but their bytes are not valid UTF-8. Rather than filling the pane with replacement characters, the tool detects that the bytes are not text and shows a hex dump plus a Download .bin button, so you can save the original bytes intact.

What is the difference between Base64 and base64url?

They share an alphabet except for two characters. Standard Base64 uses + and / for the two highest codes; base64url uses - and _ so the result can sit in a URL or a filename without being percent-encoded. base64url also usually drops the trailing = padding. Tick the URL-safe alphabet to encode with - and _, and to accept them when decoding; JWTs, for example, always use base64url without padding.

Does the padding toggle change the data?

No. The = characters carry no data; they only indicate how many bytes the final group holds. Removing them makes the string shorter and safe to put in a URL. The one rule that never changes is that the unpadded length must leave a remainder of 0, 2 or 3 when divided by four — a remainder of 1 always means characters are missing.

I pasted a data URL and the preview shows an image. Where did it come from?

A data URL such as data:image/png;base64,iVBOR… carries its own MIME type in the prefix. The tool strips that prefix, decodes the payload, and builds the preview from the bytes with a blob URL, so the image is rendered from your paste alone — nothing is fetched from the network.