Base64 Encoder & Decoder

What Base64 actually is

Base64 isn't encryption, and it isn't compression. It's an encoding — a way of representing binary data using only 64 printable characters (A–Z, a–z, 0–9, + and /, with = used as padding).

It exists because a lot of systems were built to carry text, not arbitrary bytes. Email was the original driver: attachments have to travel through mail systems that only reliably handle plain text, so the binary file is converted into safe characters first. The same reasoning applies to embedding images directly in HTML or CSS, putting binary payloads inside JSON, and storing certificates and keys in text files.

The trade-off is size. Base64 represents every 3 bytes of input as 4 characters of output, so encoded data is about 33% larger than the original. That's why it's used for convenience and compatibility, not efficiency.

Base64 provides no security. Anyone can decode it instantly — including this page. It's sometimes used to lightly obscure a value, but that's obfuscation, not protection. Never treat Base64 as a way to hide a password or a secret.

Unicode, and why many Base64 tools break

This is the most common failure in online Base64 tools, and it's worth understanding.

Browsers have built-in functions called btoa and atob for Base64. They're convenient, but they only handle characters in the Latin-1 range. Give btoa an emoji, a Devanagari character, or Chinese text and it throws an error — usually InvalidCharacterError: The string to be encoded contains characters outside of the Latin1 range. Some tools crash on this; others silently mangle the text.

The correct approach is to convert the text to UTF-8 bytes first, then Base64-encode those bytes. Decoding reverses the process. This tool does that, so anything you can type encodes and decodes back exactly as you entered it — emoji, accents, any script, mixed together.

If you've hit that InvalidCharacterError in your own code, the fix is the same: use TextEncoder to get UTF-8 bytes before encoding, rather than passing the string straight to btoa.

Standard vs URL-safe Base64

Standard Base64 uses + and / as its last two characters, and = for padding. All three cause problems in URLs: + can be interpreted as a space, / is a path separator, and = is used in query strings.

URL-safe Base64 (defined in RFC 4648) solves this by using - instead of + and _ instead of /, and usually dropping the padding altogether. The encoded data is otherwise identical, so you can convert between the two forms by swapping those characters.

You'll encounter URL-safe Base64 in JSON Web Tokens, in URL parameters, and in filenames. If a value you're decoding contains - or _ but no + or /, it's almost certainly the URL-safe variant.

Padding, and why it's sometimes missing

The = characters at the end of Base64 aren't part of the data — they pad the output to a multiple of four characters. You'll see one or two, or none at all, depending on the input length.

Some systems strip padding, particularly in URL-safe contexts. That's valid, and this tool restores it automatically when decoding, so unpadded input works fine. If another tool rejects unpadded Base64, adding = characters until the length is a multiple of four will usually fix it.

Common uses

• Data URLs — embedding a small image or font directly in HTML or CSS as data:image/png;base64,..., avoiding a separate network request.
• Email attachments — MIME encodes binary attachments as Base64, wrapped at 76 characters per line.
• JSON payloads — JSON has no binary type, so binary content is usually Base64-encoded into a string field.
• Basic authentication — HTTP Basic Auth sends username:password Base64-encoded. Worth repeating: that's encoding, not encryption, which is exactly why Basic Auth should only ever be used over HTTPS.
• JSON Web Tokens — a JWT is three URL-safe Base64 sections separated by dots. Decoding the middle section shows the token's claims in plain JSON.
• Certificates and keys — PEM files are Base64-encoded binary wrapped in -----BEGIN...----- markers.

Frequently asked questions

Is my data sent to a server?

No. Encoding and decoding happen entirely in your browser. Your text and any files you select never leave your device.

Is Base64 secure? Can I use it to hide a password?

No. Base64 is trivially reversible — anyone can decode it in seconds. It provides no security whatsoever. Use proper encryption for anything that needs protecting.

Why do other tools fail on emoji or non-English text?

Because they use the browser's btoa function directly, which only supports Latin-1 characters and throws an error on anything else. This tool converts text to UTF-8 bytes first, so any character encodes correctly.

What's the difference between standard and URL-safe Base64?

URL-safe uses - and _ in place of + and /, and usually omits the = padding, so the result can be used in URLs and filenames without escaping.

Why is my encoded output bigger than the input?

Base64 turns every 3 bytes into 4 characters, so output is roughly 33% larger. That's inherent to the format.

Can I encode a file?

Yes — select or drag in a file and it's encoded locally in your browser. There's no hard limit, but there are practical ones: Base64 output is about a third larger than the input, and very large files become slow to process and unwieldy to copy out of a text box. The tool warns you above a few megabytes. For large files, a desktop tool will handle it more comfortably than a browser.

What does the = at the end mean?

It's padding to make the length a multiple of four. It carries no data, and some systems omit it.

Is it free?

Yes, completely free with no sign-up.