Base64 encode and decode

How to use

1. Pick Encode to turn text or a file into Base64, or Decode to turn Base64 back into bytes.
2. Type or paste into the box, or switch to File and choose a file. Files up to 25 MB are read in your browser; they are not uploaded.
3. When encoding text, leave Text to bytes on UTF-8 unless the receiving system specifically wants Latin-1. Choose the alphabet: standard (+ and /) for email, data URIs and most APIs, URL-safe (- and _) for URLs, file names, and JWTs. Switch padding off if the receiver expects none.
4. Use Line breaks only when a format asks for them: 76 characters per line is the MIME rule (RFC 2045), 64 is the PEM rule (RFC 7468).
5. When decoding, leave the alphabet on Auto-detect unless you want to test one alphabet. The tool decodes the bytes and then shows them as UTF-8 text, Latin-1 text or a hex dump. If the input is wrong, the red box gives the position, line and column, and the reason; Select the problem character jumps to it.
6. Use Copy result, Download (decoded bytes are saved exactly, so binary files survive) or Use result as input to chain a decode after an encode.

The strictness switches mirror the choices the standards leave open. Ignore whitespace follows RFC 2045 (decoders must skip line breaks). Require padding follows RFC 4648 section 3.2. Strict trailing bits follows section 3.5, which lets a decoder reject a last character whose unused bits are not zero.

Worked examples

Each value below is checked by an automated test that runs the same input through the tool; the expected strings were worked out by hand from the bit patterns first.

Plain ASCII text

Thirteen bytes make four full groups of three plus one leftover byte, so the output ends in ==. The groups are SGVs, bG8s, IFdv, cmxk and IQ==.

UTF-8 or Latin-1: same letter, different bytes

The letter é is code point U+00E9. UTF-8 writes it as two bytes, C3 A9; Latin-1 writes it as the single byte E9. The Base64 differs accordingly, and a decoder that assumes the other encoding will misread it.

A character Latin-1 cannot hold

The euro sign U+20AC is three bytes in UTF-8 (E2 82 AC) and does not exist in Latin-1.

Padding and the URL-safe alphabet

RFC 4648 section 10 gives BASE64("fo") = "Zm8=". Without padding the same bytes are Zm8. The three bytes FB FF BF split into the 6-bit values 62, 63, 62, 63, which is exactly where the two alphabets differ.

Decoding

What goes wrong

These are the failures people actually hit. The messages are the tool's exact output.

btoa() and Latin-1 refuse characters above U+00FF

Browsers' btoa() does the same: it throws for any character above U+00FF. Here the Latin-1 option gives:

A Base64URL string pasted into a standard-only decoder

JWT parts, URL tokens and file names use - and _. A decoder fixed to the standard alphabet rejects them. Leave the alphabet on Auto-detect, or choose URL-safe.

Padding stripped by a URL or a tool

Browsers' atob() accepts this, because the WHATWG algorithm tolerates missing padding. Strict decoders do not. With "Require padding" on:

Wrong amount of padding

Two Base64 strings pasted together

Concatenating two encoded strings is not the same as encoding the concatenated data. The first = ends the data, so anything after it is an error:

Truncated data (5 characters)

A "+" that a URL turned into a space

The standard alphabet contains +, and in a query string or HTML form a + is read as a space. If the receiver turned each plus into a space and you decode with "Ignore whitespace" on, the spaces vanish silently and the bytes are wrong. Turn "Ignore whitespace" off and the same text is reported: Found a space at position 1, but whitespace is not allowed in strict mode. Percent-encode the Base64 when it travels in a URL, or use the URL-safe alphabet.

Latin-1 bytes decoded as UTF-8

Limits & gotchas

• Size limits are this tool's, not the standard's. Files over 25 MB are refused, and only the first 1,000,000 characters of a result are displayed (Copy and Download still use all of it). The limits exist because everything is held in your browser's memory; the right numbers for your device may differ.
• Base64 is not encryption and not compression. Output is 4 characters per 3 bytes, about a third larger than the input (RFC 4648 section 4), plus line breaks if you ask for them.
• "Latin-1" here means byte value = code point. That is what btoa() and atob() do. The WHATWG Encoding Standard says the labels "latin1" and "iso-8859-1" mean windows-1252 in the web platform, where bytes 80 to 9F map to other characters (for example 80 is the euro sign). This tool does not apply windows-1252; if your data came from a Windows program, bytes in that range will not show as you expect.
• Different decoders disagree on sloppy input. The WHATWG atob() algorithm removes whitespace, accepts missing padding and silently discards non-zero trailing bits, so YQ and YR both give "a". RFC 4648 says decoders must reject characters outside the alphabet unless the referring specification says otherwise, and RFC 2045 says MIME decoders ignore them. Node's Buffer.from(s, 'base64') skipped a stray ! when tested on Node 20.19.2; we did not find that documented, so treat it as observed behaviour. This page defaults to tolerant on whitespace, tolerant on padding, and lets you switch each one to strict.
• Non-canonical last characters. Zh== and Zg== both decode to "f" (RFC 4648 section 3.5). By default we accept it and add a note; "Strict trailing bits" rejects it.
• Other flavours are not covered. Base32, Base16 and the IMAP "modified base64" are different encodings. Radix-64 with a CRC (OpenPGP armor) is not handled.
• Data URIs: a leading data:...;base64, is removed when decoding, and the tool says so. Nothing else about the media type is interpreted.
• The share link contains your text in the address (after #), limited to about 3,000 characters. File contents are never put in a link. Do not share links containing secrets.

FAQ

Sources

• IETF: RFC 4648: The Base16, Base32, and Base64 Data Encodings Used for: The two Base64 alphabets (tables 1 and 2), padding (3.2), rejecting non-alphabet characters (3.3), canonical encoding and zero pad bits (3.5), no line feeds unless a referring spec says so (3.1), the "base64url" name (5), the test vectors (10), the "=" percent-encoding remark (5).
• IETF: RFC 2045: MIME Part One, section 6.8 Base64 Content-Transfer-Encoding Used for: Encoded lines of at most 76 characters; decoders must ignore line breaks and characters outside the alphabet.
• IETF: RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures Used for: The PEM-style Base64 body uses lines of exactly 64 characters except the last.
• WHATWG: Infra Standard: forgiving-base64 decode Used for: What browsers do in atob(): strip ASCII whitespace, accept missing padding, fail when the length leaves a remainder of 1, and discard non-zero trailing bits ("YQ" and "YR" both give "a").
• WHATWG: HTML Standard: atob() and btoa() Used for: btoa() throws InvalidCharacterError for any code point above U+00FF and otherwise treats each character as one byte; atob() throws on failure.
• WHATWG: Encoding Standard: encodings and labels Used for: The labels "latin1", "iso-8859-1" and "ascii" all name windows-1252 in the web platform, not strict ISO-8859-1.
• IETF: RFC 3629: UTF-8, a transformation format of ISO 10646 Used for: Valid UTF-8 byte sequences: lead bytes, continuation bytes, overlong forms, surrogates and U+10FFFF are not allowed.
• Node.js: Buffer: buf.toString() encodings and Buffer.from() Used for: Node's "base64" and "base64url" encodings, used only as an independent oracle in the unit tests.

Every document above was opened and read on 2026-10-02. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• URL encode and decode

  encodeURIComponent, encodeURI and form encoding side by side, with a double-encoding detector.

• JWT decoder

  Read a token’s header, claims and dates locally. Decoding is not verification; optional HMAC check with your own secret.

• Hash and HMAC generator

  SHA-1, SHA-256, SHA-384, SHA-512 and HMAC for text or files, with standard test vectors.