What is Base64 encoding and when should you use it?

Base64 encoding turns any sequence of bytes into text made of 64 “safe” characters: the uppercase letters A–Z, the lowercase letters a–z, the digits 0–9, + and /, with = used as padding at the end. The word “Hello” becomes SGVsbG8=, and a photo becomes a long string of the same kind of characters. You use it when you have to put binary data (or text that might be damaged in transit) into a place that only accepts plain text: an email, a JSON field, an HTML or CSS file, an HTTP header. The standard that defines it today is RFC 4648. To try it on your own text, paste it into the Base64 encoder and decoder.

How Base64 works, step by step

Computers store everything as bytes of 8 bits. Base64 regroups those bits into chunks of 6 bits instead. Six bits can hold 64 different values (2⁶ = 64), and each value is written as one character from the Base64 alphabet. RFC 4648 describes it as encoding “24-bit groups of input bits as output strings of 4 encoded characters”: 3 bytes in, 4 characters out.

Here is the word “Man”, the classic example. You can see the bits of each letter with the text to binary converter:

Step	M	a	n
Byte value	77	97	110
Bits	01001101	01100001	01101110

Join the 24 bits and cut them into four groups of 6:

6-bit group	010011	010110	000101	101110
Value	19	22	5	46
Base64 character	T	W	F	u

So “Man” encodes to TWFu. Decoding runs the same steps backward: look up each character’s value, join the 6-bit groups, and cut them into 8-bit bytes again.

The alphabet maps values to characters in this order:

Values	Characters
0–25	A–Z
26–51	a–z
52–61	0–9
62	+
63	/
padding	=

Why Base64 strings end with = or ==

The input is rarely a multiple of 3 bytes. When the last group is short, the encoder fills the missing bits with zeros and adds = signs so the output length is still a multiple of 4. These results come from our tool:

Text	Bytes	Base64	Padding
Man	3	TWFu	none
Ma	2	TWE=	one =
M	1	TQ==	two ==
Hello	5	SGVsbG8=	one =
Hello, world!	13	SGVsbG8sIHdvcmxkIQ==	two ==

The = sign can only appear at the end. If you see it in the middle of a string, you are probably looking at two Base64 values stuck together.

RFC 4648 says encoders must add padding unless the format using Base64 says otherwise, and notes that padding can be skipped when the length of the data is known some other way. That is why some systems, such as JSON Web Tokens, leave it out. Our decoder adds the missing = back itself, so SGVsbG8 decodes to “Hello” too.

Base64 makes data about 33% bigger

Since every 3 bytes become 4 characters, encoded data is 4/3 the size of the original, about 33% larger, as the MDN Web Docs glossary also explains. A 300-byte input gives exactly 400 characters; a 3 MB image becomes about 4 MB of text. Email adds a little more: the MIME standard (RFC 2045) requires Base64 in email to be split into lines of no more than 76 characters, and each line break adds bytes.

This size cost is the main reason not to use Base64 when you don’t have to. If a channel can carry raw bytes (a file upload, a binary download, a database BLOB column), send the bytes.

Text, UTF-8 and emoji

Base64 encodes bytes, not letters. Before text can be encoded it has to be turned into bytes with a character encoding, and the same text gives different Base64 depending on that choice. Our Base64 tool always uses UTF-8, the encoding used by almost all web pages, so plain English letters take 1 byte each, accented letters 2 and emoji 4:

Text	UTF-8 bytes	Base64
héllo	6	aMOpbGxv
👋	4	8J+Riw==
Héllo 👋	11	SMOpbGxvIPCfkYs=

You can see these bytes in hex with the text to hex converter. This matters for developers: JavaScript’s built-in btoa() treats each character as one byte, and MDN notes that it throws an error for characters above code point 0xFF, so emoji fail. The fix is to convert the text to UTF-8 bytes first, which is what our tool does.

When you decode Base64 that holds an image, a PDF or encrypted data, the bytes are not text. Our decoder still shows them as text, with � replacement characters for bytes that are not valid UTF-8, and adds a note under the result: “The decoded bytes are not valid UTF-8 text (N bytes): this is probably a file or binary data.” For example, iVBORw0KGgo=, the start of a PNG file, decodes to �PNG followed by control characters, and the note reports 8 bytes. That output is not the file and cannot be copied back into one.

Standard Base64 vs URL-safe Base64

+ and / have special meanings in URLs (/ separates path segments, + can mean a space in query strings), and = separates names from values. RFC 4648 section 5 therefore defines a second alphabet, Base64url, that swaps the two characters:

	Standard Base64	Base64url
Value 62	+	-
Value 63	/	_
Padding	= required by default	usually left out
???>>> encodes to	Pz8/Pj4+	Pz8_Pj4-
👋 encodes to	8J+Riw==	8J-Riw

JSON Web Signatures and JSON Web Tokens (RFC 7515) use Base64url “with all trailing ‘=’ characters omitted” and no line breaks. In our tool, tick URL-safe (- and _ , no padding) to get this form. The decoder accepts both alphabets, so you don’t need the option to decode. If you only need to put ordinary text into a link, percent-encoding is the right tool instead; see what URL encoding is and the URL encoder.

Where you will meet Base64

• Email attachments. MIME (RFC 2045) uses Base64 to send files through mail systems built for 7-bit text, in lines of up to 76 characters.
• Data URLs. A small image or font can be embedded straight into HTML or CSS as data:image/png;base64,.... MDN gives data:text/plain;base64,SGVsbG8sIFdvcmxkIQ== as an example; it decodes to “Hello, World!”. Our tool removes a leading data:...;base64, prefix by itself, so you can paste the whole data URL and decode it.
• HTTP Basic authentication. RFC 7617 joins the user name and password with a colon and Base64 encodes the result. Its example, user “Aladdin” with password “open sesame”, is sent as Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==, which our tool decodes straight back to Aladdin:open sesame.
• JSON and APIs. JSON has no binary type, so APIs often send file contents, keys and signatures as Base64 strings.
• Tokens. The three parts of a JSON Web Token are Base64url, which is why you can read a token’s header and claims by decoding the first two parts.

When not to use Base64

• To hide or protect data. Base64 has no key. RFC 4648’s security section says it “does not provide any computational confidentiality”, and RFC 7617 calls Basic authentication’s password handling “cleartext transmission”. A password in Base64 is a password anyone can read. Use HTTPS and real encryption.
• For large files. The extra 33% costs bandwidth and memory; embedding a large image as a data URL also stops the browser from caching it separately.
• To escape text for HTML or URLs. Use HTML entities for HTML and percent-encoding for URLs. They keep the text readable and are what those formats expect.

How to encode or decode Base64 with our tool

1. Open the Base64 encoder and decoder and paste your text or Base64 string.
2. Choose Encode text → Base64 or Decode Base64 → text under Direction.
3. Tick URL-safe if the result is going into a URL, a file name or a token.
4. Tick Each line separately if every line is its own value, such as a list of encoded IDs. Without it, line breaks are removed and the lines are treated as one string.
5. Copy the result. Everything runs in your browser; nothing is uploaded.

If decoding fails with “This is not Base64”, the input has a character outside the two alphabets, often a quotation mark or a hidden character copied from a document; remove invisible characters and try again. If it says “This Base64 is incomplete or has = in the wrong place”, part of the value is missing or two values were joined; for one value per line, tick Each line separately.