What Is Base64?
The Base64 Encoder & Decoder converts text to and from Base64, the encoding scheme that represents binary data as plain ASCII characters. Base64 is everywhere in modern development: data URLs for inline images, JSON Web Tokens (JWT), email attachments, HTTP Basic Auth headers and API payloads that must travel safely through text-only channels. This tool encodes and decodes full UTF-8, so accented characters, symbols and emoji round-trip correctly. The auto-detect mode inspects your input and decides whether to encode or decode for you, while manual Encode and Decode modes give you full control. Everything runs locally in your browser, so even sensitive tokens never leave your device.
Base64 is an encoding scheme that converts binary data — bytes with any value from 0 to 255 — into a string of printable ASCII characters. It was designed to safely carry binary content (images, files, executable code) through systems that were built to handle text, such as email, URLs and HTML attributes. The name comes from the 64-character alphabet it uses: A–Z, a–z, 0–9, + and /.
Base64 mistakes worth avoiding
Treating it as a security measure
Base64 has no key and no secret. Anything encoded can be decoded instantly by anyone, including this page. Encoding a password or an API key before storing or transmitting it adds no protection whatsoever — it only makes the value harder for a human to recognise at a glance, which is not the same thing.
Calling btoa() on non-Latin1 text
The browser's built-in btoa() only accepts characters up to U+00FF and throws an InvalidCharacterError on anything beyond it. Any accented word, any emoji, any Cyrillic or CJK character will break it. The fix is to convert to UTF-8 bytes first with TextEncoder, then encode those bytes — which is what this tool does.
Mixing the standard and URL-safe alphabets
Standard Base64 uses + and /, both of which have meaning inside a URL: + is read as a space in a query string and / splits a path. The URL-safe variant swaps them for - and _. Feeding one decoder the other alphabet produces corrupted bytes rather than a clean error, so the failure appears far from its cause.
Forgetting that it grows the payload
Three bytes become four characters, so encoded data is about 33% larger than the original, plus padding. Inlining a large image as a data URL can therefore cost more bandwidth than a second request would have, and it cannot be cached separately from the document that carries it.
Standard vs URL-safe alphabet
Both variants encode identical bytes; only three positions differ. RFC 4648 defines them as sections 4 and 5 respectively.
| Position | Standard (RFC 4648 §4) | URL-safe (§5) | Why it changes |
|---|---|---|---|
| Index 62 | + | - | A plus sign decodes as a space in query strings |
| Index 63 | / | _ | A slash is a path separator in URLs |
| Padding | = (required) | = (often omitted) | A literal = must be percent-encoded in a URL |
| Indexes 0-61 | A-Z a-z 0-9 | A-Z a-z 0-9 | Identical in both variants |
JWTs use the URL-safe variant with padding stripped, which is why a JWT segment pasted into a standard decoder can fail until you re-add the = characters.
How Base64 Encoding Works
The encoder reads the input three bytes at a time (24 bits) and splits them into four 6-bit groups. Each 6-bit value maps to one character in the 64-character alphabet, producing four ASCII characters for every three bytes. If the input length is not a multiple of three, one or two = padding characters are added to complete the last group.
Decoding reverses the process: each character maps back to its 6-bit value, groups of four are merged into 24 bits, then split into three bytes. Padding = characters tell the decoder how many real bytes are in the final group.
Encoding & Decoding Locally
Base64 encoding and decoding both run as JavaScript algorithms in your browser. The data you encode or decode is processed locally on your machine and never sent to external servers.