Base64 Decode and Encode

How to use it

1. Choose Decode to read Base64, or Encode to create it.
2. Paste your Base64 (a data:image/...;base64, prefix is fine), or type the text you want to encode.
3. When encoding, tick URL-safe if the result goes into a link or file name. It swaps + and / for - and _ and removes the = padding.
4. Read the result, press Copy result, or use Download file when the data is an image or other binary.

What Base64 is

Base64 is a way to write any bytes using only 64 safe characters: the letters A-Z and a-z, the digits 0-9, plus + and /. Email, URLs, JSON and HTML were built for text. If you push raw bytes through them, some bytes get mangled or rejected. Base64 turns the bytes into plain text first, and the receiver turns them back.

The price is size. Every 3 bytes become 4 characters, so the encoded version is about 33 percent larger.

How the encoding works

The method is short. Take 3 bytes, which is 24 bits. Split those 24 bits into four groups of 6 bits. Each 6-bit group is a number from 0 to 63, and that number picks a character from the alphabet.

The Base64 alphabet

Worked example: "Hello" becomes SGVsbG8=

"Hello" is five bytes: 72, 101, 108, 108, 111. In binary that is:

01001000 01100101 01101100 01101100 01101111

Take the first three bytes (H, e, l) as one 24-bit block and re-cut it into 6-bit groups:

Two bytes remain (l, o), which is only 16 bits. Cut them into 6-bit groups: 011011, 000110, and then 1111 with two zeros added to make 111100. That gives the values 27, 6 and 60, which are b, G and 8. Three characters cover 16 bits, so the fourth place is filled with a padding sign: =.

Joined together: SGVsbG8=. You can check it by pasting it into the tool on this page.

Padding rules

The padding depends on how many bytes are left over in the last block.

• Input length is a multiple of 3: no padding. "Man" becomes TWFu.
• One byte left over: two = signs. "M" becomes TQ==.
• Two bytes left over: one = sign. "Ma" becomes TWE=, and "Hi" becomes SGk=.

Padding is only there to keep the length a multiple of 4. Many systems drop it, especially in URL-safe Base64, and this decoder adds it back if it is missing. A length that leaves a remainder of 1 when divided by 4 can never be valid, because one character carries only 6 bits and a byte needs 8.

Decoding by hand

Run the process backward. Look up each character's value, write it as 6 bits, join all the bits, cut them into bytes of 8, and ignore leftover bits at the end. For "SGk=", the characters are S=18, G=6, k=36. Their bits are 010010 000110 100100. That is 18 bits, which gives two full bytes (01001000 and 01101001) and 2 leftover zero bits. The bytes are 72 and 105: "Hi".

Standard versus URL-safe Base64

The + and / characters cause trouble in links and file names. RFC 4648 defines a second alphabet that replaces them with - and _. The text "subjects?_d" is a good test:

• Standard: c3ViamVjdHM/X2Q=
• URL-safe: c3ViamVjdHM_X2Q

The tool's Encode mode has a URL-safe checkbox that makes the second form, with padding removed. The Decode mode accepts either one, so you never need to convert by hand.

Text with accents and emoji

Base64 encodes bytes, not letters. Before text is encoded, it has to be turned into bytes, and the usual choice is UTF-8. Plain English letters are one byte each. The letter é is two bytes (C3 A9) and encodes as w6k=. The emoji 😀 is four bytes and encodes as 8J+YgA==. This tool always uses UTF-8, so those round trip correctly.

A well-known trap is JavaScript's own btoa() and atob() functions. They only handle characters up to code 255, so btoa("é€") throws an error. The usual workaround is to convert text to UTF-8 bytes first, which is what this tool does.

Base64 images and data URIs

Small files can be placed directly in a web page. The format is data:image/png;base64, followed by the Base64 text. This saves a network request and is common for tiny icons and in email templates. It is a poor choice for large images, because of the 33 percent size increase and because the browser cannot cache them separately.

If you paste a full data URI here, the tool removes the prefix, decodes the rest and checks the first bytes of the file. A PNG starts with 89 50 4E 47, a JPEG with FF D8 FF, a GIF with the letters GIF, and WebP with RIFF. On a match you get a preview and a download button.

Common mistakes

• Treating Base64 as encryption. It protects nothing. Basic authentication headers, for instance, are only Base64, and anyone who sees one can read the password.
• Dropped or extra characters. A single lost character shifts every bit after it, and the output becomes nonsense. A length remainder of 1 is the clearest sign.
• Line breaks. Old email standards wrap Base64 at 76 characters. The tool ignores whitespace, but other software may not.
• Mixing alphabets. A string with - or _ is URL-safe. Using it in a strict standard decoder fails.
• Binary output shown as text. If the bytes are not valid UTF-8, you see replacement marks. That means the data is a file, not a message.
• Double encoding. If the decoded result is itself Base64, someone encoded twice. Decode it again.

Related encodings

Hex uses 2 characters per byte. It is easy to read and is the standard for hashes, but it doubles the size. Binary uses 8 characters per byte and is mostly for learning. RFC 4648 also defines Base32 (5 bits per character, case-insensitive, used in one-time password setup codes) and Base16, which is simply hex.

A short history

Base64 came out of email. Early mail systems carried only 7-bit text, so binary attachments had to be converted. Several similar schemes appeared in the 1980s, including uuencode and a version in Privacy Enhanced Mail. The MIME standard of 1992 made Base64 the common form for attachments. RFC 4648, published in 2006, collected the rules in one document, including the URL-safe alphabet.

Sources

• RFC 4648: The Base16, Base32, and Base64 Data Encodings
• RFC 3629: UTF-8, a transformation format of ISO 10646
• MDN: Window.atob()
• MDN: data: URLs

Checked October 2026.