Base64 turns up everywhere: JWTs, data URIs, OAuth tokens, email attachments. The ChrysoKit Base64 Encoder & Decoder is the small tool you reach for when you need to look at, or massage, a Base64 string.
Why use it
Encoding and decoding are one click apart, both directions are fully Unicode-safe, and URL-safe Base64 is a single checkbox away. Local-only, so private tokens never leave the page.
How to use the Base64 Encoder & Decoder
- Pick the Encode tab to convert plain text to Base64, or Decode to go the other way.
- Paste your input.
- Tick URL-safe if you need the JWT-style alphabet (uses -_ and omits padding).
- Copy the result with one click.
Features worth knowing
Full Unicode
Emojis, accented characters and CJK text all round-trip cleanly.
URL-safe mode
Replaces + and / with - and _, and strips the = padding. Required inside JWTs and many OAuth flows; standard Base64 will fail validation.
Encode and decode tabs
Switch direction with one click instead of finding a separate tool.
Pro tips
- Base64 is encoding, not encryption. Anything you can encode, anyone else can decode.
- URL-safe Base64 is required inside JWTs and many OAuth flows. Standard Base64 will fail validation.
- Padding (the '=' at the end) is sometimes stripped. Most decoders tolerate it either way; the tool does too.
- If you need to Base64 an image, use the Image to Base64 tool, which handles binary properly.
Privacy first. The Base64 Encoder runs entirely in your browser. Nothing you encode is uploaded.
Bookmark the Base64 tool; you will need it more than you expect.
Open the tool: Base64 Encoder →
Spotting Base64 in the wild: a field guide
Once you know its silhouette, Base64 appears everywhere: a long run of letters and digits, perhaps ending in one or two equals signs. Developing the reflex to recognise and decode it on sight turns several opaque situations transparent.
In a browser's developer tools, that data:image/png;base64,iVBORw... string is an embedded image; the prefix iVBOR is so characteristic it identifies PNG on sight (JPEGs start /9j/). In an email's raw source, the attachment is a wall of Base64 inside MIME boundaries... and the encoding's 33% overhead explains why a 15 MB attachment bounces against a 20 MB limit. In an API response, a field of suspicious letter-soup often decodes to nested JSON some upstream service wrapped for transport. In a JWT, each dot-separated section decodes independently. In a configuration file, a "mysterious" credential blob frequently decodes to plain username:password... which is the moment to remember, forcefully, that Base64 conceals nothing.
That last point carries the field guide's security corollary: attackers know the silhouette too, and Base64 is a favourite costume for obfuscated scripts precisely because it defeats naive keyword scanning while remaining trivially reversible. Decoding suspicious strings before judging them is standard analyst practice. The encoding is a transport format wearing the costume of a cipher... treat anything "protected" by it as already public.