Base64 Encode/Decode

About Base64 Encode/Decode

How Base64 Encoding Works

Base64 takes every 3 bytes (24 bits) of input and splits them into four 6-bit groups. Each 6-bit value maps to one of 64 characters: A-Z (0-25), a-z (26-51), 0-9 (52-61), + (62), and / (63). If the input length is not a multiple of 3, the output is padded with = characters to make it a multiple of 4.

Input Text	Bytes	Base64 Output	Padding
Man	4D 61 6E (3 bytes)	TWFu	None
Ma	4D 61 (2 bytes)	TWE=	1 pad
M	4D (1 byte)	TQ==	2 pads
Hello	48 65 6C 6C 6F	SGVsbG8=	1 pad

The encoding always increases size by about 33%. Three bytes of input become four characters of output, so a 30KB file becomes roughly 40KB when Base64-encoded.

Base64 vs Base64URL

Standard Base64 uses + and / as the 63rd and 64th characters, plus = for padding. These characters have special meaning in URLs (+ means space, / is a path separator, = is used in query parameters). Base64URL replaces them:

Variant	Character 62	Character 63	Padding	Used In
Standard Base64 (RFC 4648 Section 4)	+	/	= required	Email (MIME), PEM certificates, data URIs
Base64URL (RFC 4648 Section 5)	-	_	Optional (usually omitted)	JWTs, URL parameters, filenames

When you see a Base64 string containing - and _ instead of + and /, it is Base64URL-encoded. JWTs use Base64URL for all three segments (header, payload, signature). This tool handles standard Base64. For JWT inspection, the JWT Decoder handles Base64URL automatically.

Where Base64 Is Used

Use Case	How Base64 Is Used	Example
Data URIs	Embed images/fonts directly in HTML or CSS	data:image/png;base64,iVBOR...
HTTP Basic Auth	Encode username:password in Authorization header	Authorization: Basic dXNlcjpwYXNz
Email (MIME)	Encode binary attachments for text-only transport	Content-Transfer-Encoding: base64
JSON payloads	Embed binary data in JSON (which only supports text)	{"file": "SGVsbG8gV29ybGQ="}
PEM certificates	Encode DER-format certificates as text	-----BEGIN CERTIFICATE-----
Source maps	Inline source maps in JavaScript bundles	//# sourceMappingURL=data:application/json;base64,...

Base64 Is Not Encryption

A common misconception is that Base64 provides some form of security. It does not. Base64 is a reversible encoding, not encryption. Anyone can decode a Base64 string instantly - there is no key, no password, and no secret. Never use Base64 to "hide" sensitive data like passwords, API keys, or personal information.

Property	Base64 Encoding	AES Encryption
Purpose	Represent binary as text	Protect data confidentiality
Key required?	No	Yes (secret key)
Reversible by anyone?	Yes - trivially	No - only with the key
Size change	+33%	Varies (block padding)
Use case	Transport encoding	Data protection

UTF-8 and Multi-Byte Characters

Base64 operates on bytes, not characters. For text containing non-ASCII characters (accented letters, CJK characters, emoji), the text must first be converted to bytes using a character encoding - almost always UTF-8.

Character	UTF-8 Bytes	Base64
A	41 (1 byte)	QQ==
e with accent	C3 A9 (2 bytes)	w6k=
Chinese character	E4 B8 AD (3 bytes)	5Lit
Emoji	F0 9F 98 80 (4 bytes)	8J+YgA==

JavaScript's built-in btoa() function only handles Latin-1 characters. This tool uses the TextEncoder API to properly handle the full Unicode range, so emoji and CJK characters encode and decode correctly.

Base64 in the Command Line

OS	Encode	Decode
macOS / Linux	echo -n "text" | base64	echo "dGV4dA==" | base64 -d
Windows (PowerShell)	[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("text"))	[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("dGV4dA=="))

The macOS base64 command uses -D (capital) for decode, while Linux uses -d (lowercase). This tool avoids those platform differences entirely.

For encoding image files specifically, the Image to Base64 converter handles file upload and generates ready-to-use data URIs. For URL-safe percent encoding of query parameters, the URL Encoder/Decoder is the right tool. All processing happens in your browser - your data stays on your machine.

Worked Example: Encoding "Cat"

Take the three-letter string "Cat". In ASCII, the bytes are 0x43 0x61 0x74, which in binary is 01000011 01100001 01110100 - exactly 24 bits. Base64 regroups these 24 bits into four 6-bit chunks: 010000, 110110, 000101, 110100, giving decimal values 16, 54, 5, 52. Mapping those to the Base64 alphabet (A=0, Q=16, 2=54, F=5, 0=52) produces "Q2F0". Because the input was already a multiple of 3 bytes, no padding is needed. Decoding reverses the process exactly - no information is lost. This round-trip lossless property is why Base64 works for binary formats like JPEG, PDF, and executable files where losing a single bit would corrupt the file.

How Much Does Base64 Cost in Real Files?

Base64 adds about 33% in raw size plus up to 3 padding characters. For real-world files, the total overhead can be higher once you account for line wrapping (RFC 2045 MIME wraps every 76 characters, adding 1-2 bytes per 76) and the data URI prefix. The table below shows the actual on-disk size for common file sizes, based on RFC 4648 encoding without line breaks.

Original Size	Raw Base64	With MIME Line Wrap	With data:image/png Prefix
100 bytes	136 bytes	139 bytes	158 bytes
1 KB	1.33 KB	1.37 KB	1.37 KB
10 KB (small PNG)	13.33 KB	13.62 KB	13.36 KB
100 KB	133.3 KB	136.2 KB	133.4 KB
1 MB	1.33 MB	1.37 MB	1.33 MB

Google PageSpeed Insights generally advises against inlining images larger than about 4 KB as data URIs. Above that threshold, the render-blocking cost of a large inline blob and the cache-busting effect of repeated inlining usually outweighs the saved HTTP request. HTTP/2 and HTTP/3 multiplexing further reduce the case for inline Base64 on production sites.

Base64 in HTTP Basic Authentication

HTTP Basic Auth, defined in RFC 7617, encodes credentials using Base64 but this provides zero confidentiality. The server receives a header like Authorization: Basic dXNlcjpwYXNzd29yZA== where dXNlcjpwYXNzd29yZA== decodes trivially to user:password. The only real protection comes from the TLS transport - over plain HTTP, Basic Auth is equivalent to sending the password in cleartext. The MDN Web Docs and OWASP both flag Basic Auth as unsuitable for any production login flow; prefer OAuth 2.0, JWT-based sessions (decode tokens with the JWT Decoder), or SAML for modern authentication.

Common Mistakes When Decoding Base64

• Confusing Base64URL with standard Base64. JWTs, URL-safe APIs, and many OAuth flows use Base64URL (with - and _ instead of + and /). Pasting a JWT payload into a standard Base64 decoder gives "Invalid character" errors. Replace - with + and _ with / before decoding, or use a tool that auto-detects.
• Forgetting padding. Some producers strip trailing = characters. A decoder that strictly enforces padding will fail on these inputs. Add = characters until the string length is a multiple of 4.
• Mojibake from encoding mismatch. If the source encoded text as Windows-1252 and you decode as UTF-8, accented characters become replacement characters. Always match the character encoding on both sides - UTF-8 is almost always the right choice today.
• Copy-pasting from PDFs or emails. Some clients insert soft line breaks, non-breaking spaces, or zero-width characters that break decoding. Trim whitespace and strip non-Base64 characters before decoding.
• Treating Base64 as compression. Base64 expands data, never shrinks it. If you want smaller payloads, compress first (gzip, Brotli) and then Base64-encode the compressed bytes.

History and Design

Base64 was first formalised in the 1987 Privacy-Enhanced Mail (PEM) standard (RFC 989) and later codified in RFC 2045 (MIME, 1996) and the current RFC 4648 (2006). The alphabet was chosen to avoid characters that were unsafe in the text protocols of the 1980s: no control characters, no characters that required quoting in email headers, and no characters mangled by early EBCDIC-to-ASCII converters. The 64-character alphabet fits exactly into 6 bits, which is the largest power-of-two chunk size that divides evenly into 24-bit groups (the least common multiple of 6 and 8). Base32 and Base16 use the same principle with smaller alphabets for case-insensitive or human-readable contexts.

Base64 vs Similar Encodings

Base64 is one of several text-safe binary encodings, each with different trade-offs. Base16 (hexadecimal) is the most human-readable but doubles the size. Base32 fits URLs and case-insensitive filesystems, used by Gmail attachments and some TOTP secrets. Ascii85 (used in PDF and PostScript) is more compact than Base64 but uses characters that break in shell environments. The table compares typical overheads and use cases.

Encoding	Alphabet Size	Size Overhead	Typical Use
Base16 (hex)	16	+100%	Cryptographic hashes, colour codes, memory dumps
Base32 (RFC 4648)	32	+60%	TOTP secrets, some DNS records, case-insensitive filesystems
Base64 (standard)	64	+33%	MIME email, PEM files, data URIs, general binary-to-text
Base64URL	64	+33%	JWTs, OAuth tokens, URL-safe identifiers
Ascii85 / Base85	85	+25%	PDF streams, PostScript, Git binary diffs

For most modern web scenarios, Base64 or Base64URL is the right choice. Compare encoded hashes with the Hash Generator which also outputs hex for developers who prefer fixed-width output.

Sources

• IETF RFC 4648 - The Base16, Base32, and Base64 Data Encodings
• IETF RFC 2045 - MIME Part One: Format of Internet Message Bodies
• IETF RFC 7617 - The 'Basic' HTTP Authentication Scheme
• MDN Web Docs - Base64
• MDN Web Docs - Window.btoa() method
• MDN Web Docs - data: URL scheme
• OWASP Authentication Cheat Sheet