Base64 Encode / Decode

How to encode or decode Base64

1. Paste your text into the input box.
2. Choose Encode to convert plain text to Base64, or Decode to go the other way.
3. The result appears instantly as you type.
4. If decoding fails, check for missing padding (=) or characters that are not valid Base64.
5. Click Copy to grab the output.

Where you meet Base64 in real work

The middle segment of a JWT is Base64url-encoded JSON, so decoding it shows the token's claims. Basic Auth headers are 'user:password' in Base64. Data URIs embed images in CSS or HTML as Base64. Kubernetes secrets, SAML responses and email attachments all use it too.

One catch: standard Base64 uses + and /, while the URL-safe variant used by JWTs uses - and _ instead. If a JWT segment will not decode, that character difference (or stripped padding) is usually why.

Encoding is not encryption — read this first

This is the single most important thing to understand about Base64: it provides no security or secrecy whatsoever. It is a public, reversible mapping between binary data and 64 printable characters. Anyone who sees your Base64 string can decode it in one step, using this very tool, and read the original in full. There is no key, no password, and nothing to break.

So Base64 is the wrong choice for hiding a secret. If a config file stores a password 'encoded' in Base64, treat that password as plaintext. To actually protect data you need real encryption (for confidentiality) or hashing with a strong algorithm like bcrypt or argon2 (for passwords). Base64 only makes binary safe to transport as text; it never makes it private.

How the conversion works in your browser

Encoding takes your text, turns it into its UTF-8 bytes, then groups those bytes into blocks of three (24 bits) and re-splits them into four 6-bit chunks. Each 6-bit value indexes into the 64-character alphabet, which is why Base64 output is always a multiple of four characters, with = signs padding the final group when the input length is not divisible by three.

All of that arithmetic happens in JavaScript on your own device the moment you type. Nothing is sent anywhere, so the result appears instantly and the tool keeps working offline once the page has loaded. Decoding simply reverses the process: it reads four characters back into three bytes and reinterprets the byte stream as UTF-8 text.

Privacy when decoding tokens and credentials

The strings people most want to decode are exactly the ones they should never paste into a server-side tool: JWTs, Basic Auth headers, session cookies, signed webhook payloads, and secrets pulled out of a Kubernetes manifest. Because those often grant access to real systems, uploading them to inspect them would be handing over live credentials.

Here the decoding runs only in your browser, so a token you paste to peek at its claims never leaves your machine and is not logged anywhere. When you close the tab it is gone. That said, the golden rule still applies: the fact that you can decode a JWT in a second is precisely why Base64 must never be relied on to keep any of that content secret.

Standard Base64 versus the URL-safe variant

Two flavours exist. Standard Base64 (RFC 4648) uses + and / as its 62nd and 63rd characters and pads with =. Those characters have special meaning inside URLs and filenames, so a URL-safe variant swaps + for - and / for _, and frequently drops the trailing padding entirely. JWTs, many APIs, and some filename schemes use this URL-safe form.

The mismatch is a classic source of confusion. A JWT segment copied from a browser will contain - and _ and no = signs; feed it to a strict standard decoder and it may choke. If a decode fails, checking whether you are looking at the URL-safe alphabet, and whether padding was stripped, resolves most cases without touching the actual data.

Handling Unicode, emoji and binary data

Base64 itself only knows about bytes, not characters, so text has to be turned into bytes first. This tool uses UTF-8, which means accented Latin letters, non-Latin scripts like Arabic or Chinese, and emoji all round-trip correctly: they are encoded to their multi-byte UTF-8 sequences before conversion and reassembled on the way back.

That byte-first design is also why Base64 can represent things that are not text at all, such as the raw contents of an image embedded in a data URI. When you decode such a string you will see bytes that are not printable characters, which is expected: not every Base64 blob is meant to be read as text, and a screen full of gibberish usually means the original was binary, not that decoding failed.

Related privacy-first tools

Base64 rarely travels alone. A decoded JWT segment is JSON, so paste it into the JSON formatter to lay out the claims cleanly. If a Base64 value turns out to hold a URL with escaped characters, the URL encoder and decoder makes it readable. For raw bit-level curiosity, the binary translator shows how characters map to bytes in the first place.

And when you genuinely need a one-way fingerprint rather than a reversible encoding, the hash generator computes SHA-256 and related digests. All of these run entirely in your browser in the same way, so you can chain them together on sensitive data without any of it being uploaded.

Frequently asked questions

Related tools