How to use Base64 Encode / Decode
What it does & when you need it
Base64 shows up everywhere a system needs to move binary or non-ASCII data
through a text-only channel: a data: URI in CSS, an image embedded in an email,
the payload of a JWT, a Basic auth header, or a secret pasted into a YAML file.
This tool encodes text to Base64 and decodes it back, with correct UTF-8 handling
and support for the URL-safe alphabet. It all happens locally, so decoding an
auth header or an encoded credential never sends it to a server.
How to use
- Pick Encode or Decode at the top.
- Type or paste into the left buffer, or press Sample to load an example. In Encode mode you can Upload a text file.
- Tick URL-safe to use the
-_alphabet without padding — the variant you need for query strings, filenames, and JWT segments. - The result appears on the right. Press Copy result (or
Ctrl/Cmd+Enter) to copy it.
Things worth knowing
Base64 is encoding, not encryption. It provides zero confidentiality — the transformation is public and reversible by anyone. If you can read this sentence you can decode Base64. Use it to transport data safely, never to hide it. A "password" stored as Base64 is a plaintext password.
Standard vs URL-safe alphabet. RFC 4648
defines two alphabets. The standard one (§4) uses + and /, which are
problematic in URLs because + means space and / is a path separator. The
URL-safe variant (§5) replaces them with - and _ and typically omits the =
padding. JWTs use URL-safe Base64 for exactly this reason — which is why the
JWT decoder relies on the same logic.
Why the = padding appears. Base64 packs three bytes (24 bits) into four
6-bit characters. When your input length isn't a multiple of three, the last
group is padded: one leftover byte encodes to two characters plus ==, two
leftover bytes to three characters plus =. Padding lets a decoder know how many
real bytes the final group represents.
UTF-8 matters. The classic btoa() browser function throws on any character
above U+00FF, so btoa('😀') fails. This tool encodes text as UTF-8 bytes first,
so emoji, CJK characters, and accented Latin all round-trip correctly. If a
decode produces garbled text, the bytes probably weren't UTF-8 to begin with —
they may be a raw image or a compressed stream rather than text.
Base64 grows your data ~33%. Four output characters for every three input bytes. That overhead is the price of text safety; keep it in mind before Base64-ing a large file into a JSON field — and if that field then needs tidying, the JSON formatter will pretty-print it. (A dedicated file checksum/hash generator is coming soon for verifying integrity rather than transporting bytes.)