Base64
Most tools lean on the browser's btoa, which only accepts Latin-1 and quietly corrupts anything else. Emoji, accents, and CJK round-trip exactly here.
Base64 strings carry API keys, tokens, and credentials. This page never sends them anywhere - it works with your connection switched off.
Base64 hides nothing. Anyone can decode it in a second, exactly as this page does. Never use it to protect a password or a key.
What is Base64?
Base64 is a way to write arbitrary binary data using only 64 characters that survive anywhere: A-Z, a-z, 0-9, +, and /. It exists because much of the internet's plumbing - email, URLs, JSON, XML, HTTP headers - was designed for text, and will happily corrupt, strip, or reject raw bytes.
The mechanism is simple arithmetic. Three bytes are 24 bits; split those 24 bits into four groups of six; each 6-bit group is a number from 0 to 63, which indexes the alphabet. So three bytes in, four characters out - and that ratio is the whole story of Base64, including its 33% size increase.
What the padding is for
If your data is not a clean multiple of three bytes, the last group is short. Base64 pads the output with = so the length is always a multiple of four, which tells a decoder how many real bytes the final group held. Some systems drop the padding because they know the length anyway - that is why the padding toggle is here, and why a decoder should accept it missing. This one does.
Bytes, not characters
This is the subtlety that breaks most implementations. Base64 encodes bytes, so text must first become bytes, and that requires choosing an encoding - virtually always UTF-8. The browser's built-in btoa() refuses anything above Latin-1, so tools built on it either throw or silently mangle "café", "日本語", or "🎉". This page converts through UTF-8 with TextEncoder, so every alphabet and emoji survives the round trip intact. Try it.
Base64 is not encryption
This deserves its own section, because it is the most consequential misunderstanding in the whole topic - and it shows up in real breaches.
Base64 provides zero security. There is no key, no secret, and nothing to break. It is a public, reversible transformation that anyone can undo instantly - as this very page demonstrates. It makes data unreadable to a casual human glance, and that is all.
So: never Base64 a password and call it protected. Never "obscure" an API key by encoding it. Never assume Base64 in a config file, a cookie, or a database column means the contents are safe. If someone can read the string, they can read the data.
What Base64 is genuinely for is transport: making bytes survive a text-only channel. Encryption and encoding solve different problems, and they compose well - encrypt first, then Base64 the ciphertext so it can travel through email or JSON. In that order, the Base64 layer adds nothing to the secrecy and everything to the compatibility.
Need a one-way fingerprint of some data instead? That is hashing - see the Hash Generator. Need to inspect a token's contents? A JWT is three URL-safe Base64 segments, and you can paste any of them here.
Where Base64 shows up
| Where | Looks like | Notes |
|---|---|---|
| Data URLs | data:image/png;base64,iVBORw0… | Embeds a file directly in HTML or CSS. Convenient for tiny icons; wasteful for anything larger, since it cannot be cached separately |
| HTTP Basic auth | Authorization: Basic dXNlcjpwYXNz | Just user:password encoded - not protected at all, which is why it needs HTTPS |
| JSON Web Tokens | eyJhbGciOi… | Three URL-safe segments joined by dots. The payload is readable by anyone; the signature is what makes it trustworthy |
| Email attachments | MIME, wrapped at 76 chars | The original reason Base64 exists - SMTP was built for 7-bit text |
| Keys and certificates | -----BEGIN CERTIFICATE----- | PEM format is Base64 of the binary DER, with header lines |
| API payloads | Encoded blobs inside JSON | JSON has no binary type, so bytes are Base64'd into a string |
Standard vs. URL-safe
Standard Base64's + and / are both meaningful inside a URL: + can be read as a space, and / as a path separator. URL-safe Base64 (RFC 4648 §5) substitutes - and _, and typically drops the = padding as well, so the string can sit in a query parameter or path untouched. This is what JWTs use. Flip the URL-safe toggle above and watch the characters change - the underlying bytes are identical.
Working with the URLs themselves rather than their payloads? Percent-encoding is a different scheme with a different job.
Frequently asked questions
What is Base64 encoding?
Base64 is a way of writing binary data using only 64 plain text characters: A-Z, a-z, 0-9, plus and slash. It exists because many systems - email, URLs, JSON, XML - were built for text and will corrupt or reject raw bytes. Base64 takes three bytes at a time and rewrites them as four printable characters, so the data survives any channel that can carry text.
Is Base64 encryption? Is it secure?
No. Base64 is not encryption and offers no security whatsoever. There is no key and no secret - anyone can decode it instantly, which is exactly what this page does. It only makes data look scrambled to a human eye. Never use Base64 to hide a password, an API key, or personal data. If you need secrecy, encrypt the data; Base64 only makes an already-encrypted blob safe to transport as text.
Why does Base64 make my data bigger?
Because it spends four characters to describe every three bytes, Base64 output is about 33% larger than the input, plus a little padding. That is the price of using only safe characters. It is why you should not Base64 a large image into a web page: the bytes are bigger and, unlike a real image file, they cannot be cached separately by the browser.
What is URL-safe Base64?
Standard Base64 uses plus and slash, which both have special meanings in a URL and get mangled or re-encoded. URL-safe Base64 (RFC 4648) swaps them for minus and underscore, and usually drops the equals padding too. It is what JSON Web Tokens use for each of their segments. Turn on the URL-safe option here and the output is safe to drop into a query string or a path.
Why does my decoded text show strange characters?
Usually because the tool that encoded it mishandled UTF-8. Base64 works on bytes, not characters, so text must first be turned into bytes - and the browser's own btoa function only accepts Latin-1, so many tools silently corrupt anything beyond plain ASCII. This page encodes through UTF-8 properly, so emoji, accents, Greek, Arabic, and CJK all round-trip exactly. If a decode here produces something odd, the original encoder was probably at fault.
Is my data uploaded when I encode or decode it?
No. Everything is encoded and decoded in your browser with JavaScript, including whole files, so nothing is uploaded, logged, or tracked. That matters here more than almost anywhere: Base64 strings routinely carry API keys, tokens, and credentials, and pasting those into a site that sends them to a server is a genuine leak. This page keeps working offline once loaded.