Base64 Decoder and Encoder

What the Base64 tool does

The tool turns text or a file into Base64, and Base64 back into the bytes it holds. Text is read and written as UTF-8, the encoding of the web and of most APIs, so accented letters and emoji come back exactly as they went in. When decoded bytes are not text, such as an image or a ZIP archive, you see their start in hex with their file type, and you can download them as a file. Decoding follows RFC 4648 (opens in a new tab): it takes both alphabets, with or without padding, skips spaces and line breaks, and reports each character that does not belong at its line and column.

How to decode or encode Base64

Examples

data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbImFwcC50cyJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiQUFBQSJ9

{"version":3,"sources":["app.ts"],"names":[],"mappings":"AAAA"}

{"next":"/cart?step=2"}

eyJuZXh0IjoiL2NhcnQ_c3RlcD0yIn0

"U2VydmVyIHN0YXJ0ZWQ="

Line 1, column 1: " is not a Base64 character. Base64 uses A–Z, a–z, 0–9, + and / (or - and _ in URL-safe Base64) and = at the end. (B64_INVALID_CHAR)

Decoded JSON comes out exactly as it was encoded, usually on one line; the JSON Formatter indents it, and the XML Formatter does the same for a decoded SAML response or SOAP message.

How Base64 works

Base64 writes any bytes with 64 characters that pass unchanged through email, JSON, XML and URLs: A–Z, a–z, 0–9, + and /. It reads the bytes three at a time, 24 bits, and writes each group as four characters of 6 bits. The word Cat, bytes 43 61 74, becomes Q2F0.

When the last group has one or two bytes, one or two = fill it up to four characters: C becomes Qw== and Ca becomes Q2E=. The padding carries no data, which is why the decoder here accepts Base64 without it. A length that leaves a single character over, like Q2F0Q, cannot come from whole bytes, so decoding stops with B64_BAD_LENGTH.

Every 3 bytes take 4 characters, so Base64 is a third larger than the data, plus its line breaks when it is wrapped: a 30 KB image becomes about 40 KB of text.

Base64 is an encoding, not encryption. Anyone can decode it without a key, so a password in an HTTP Basic header or a value in a cookie is as readable as plain text to whoever sees it.

URL-safe Base64 and JWTs

Two of the standard characters have a meaning in URLs: + can turn into a space in a query string, and / separates path segments. Base64url, defined in RFC 4648 §5 (opens in a new tab), uses - and _ in their place and usually drops the = padding, which a URL would need to escape too. In the second example, standard Base64 of the same text is eyJuZXh0IjoiL2NhcnQ/c3RlcD0yIn0=, with a / and an =.

JSON Web Tokens are three base64url parts joined by dots, and PKCE code challenges and many signed URLs use the same alphabet. You never choose the alphabet to decode: the decoder tells it from the characters, and reports B64*MIXED_ALPHABET when one value holds + or / together with - or *, which usually means two values ran together. When you encode, choosing URL-safe also turns padding off; turn it back on if the receiving side expects it.

Text or binary output

Base64 holds bytes, not characters, and the bytes mean whatever their writer made them mean. This tool encodes text as UTF-8, where é takes two bytes and 😀 four, and it reads decoded bytes as UTF-8. They are shown as text only when they are valid UTF-8 and hold no NUL byte.

Everything else is binary data: an image, a PDF, compressed or encrypted bytes, or text in an older encoding such as Latin-1 or UTF-16. Showing those bytes as text would print replacement characters and lose data, so the tool shows the first 256 bytes in hex, names the first byte that is not text, and recognizes common file types by their opening bytes: PNG, JPEG, GIF and WebP images, PDF, ZIP, gzip and WebAssembly. Download saves the exact bytes, with the type's extension or .bin. Images get a preview as a picture; SVG and HTML are text, so they are shown as text and never rendered.

The editor keeps line breaks as LF. To encode a file's exact bytes, CRLF line breaks included, set Input to File instead of pasting its text.

Data URIs: when embedding pays off

A data URI (RFC 2397 (opens in a new tab)) carries a whole file in a URL: data:image/png;base64, and then the file in Base64. To make one, encode a file with File output set to Data URI; the media type comes from the file, or from its first bytes. To decode one, paste the whole URI: the prefix is set aside, its media type is noted, and the rest is decoded.

Embedding saves a request, which suits small images that a page needs at once, like an icon in a stylesheet. It costs in other ways: the file is a third larger, it cannot be cached apart from the page or stylesheet that holds it, and it is downloaded again whenever that file changes. For anything beyond a few kilobytes, or used on several pages, a separate file is usually faster.

Line breaks: MIME and PEM

Some formats need Base64 in short lines. MIME email (RFC 2045 (opens in a new tab)) allows at most 76 characters per line and ends each line with CRLF. PEM files, the -----BEGIN CERTIFICATE----- blocks of TLS certificates and keys (RFC 7468 (opens in a new tab)), have exactly 64 characters per line, written with LF by most tools. Choose Line wrap to match; JSON, HTTP headers and URLs need the Base64 on one line.

The tool writes the Base64 only, so add the BEGIN and END lines yourself when you build a PEM file. When you decode, line breaks never matter, and a whole PEM block can be pasted: its BEGIN and END lines are set aside and the Base64 between them is decoded. Certificates and keys hold DER bytes, so they come out as binary data.

Options

Common errors and fixes