Base64 Encoder and Decoder

Base64 is for transport, not secrecy

Base64 paints raw bytes using a small set of readable ASCII characters. That's the whole trick. So it shows up anywhere bytes have to ride through a text-only channel: API bodies, email attachments, those old Basic Auth examples, the header and payload halves of a JWT, tiny data URIs, config blobs, log lines. Loads of systems happily shuffle text around but choke the second you hand them binary. Base64 is the bridge. Trouble is, the bridge runs both ways, and anyone holding the encoded string decodes it in a second. Lean on it like a password and you're going to have a bad day.

I wanted something I'd actually keep pinned in a tab, so this leans toward inspection instead of just coughing up a string. Sure, it does standard Base64, Base64URL, optional padding, UTF-8 text, small local files, a byte preview, data URIs. The part I care about is the why. Is this token URL-safe? Is padding missing? How many bytes are we really dealing with here? And is the decoded blob readable text, or just binary wearing a text costume.

How to use the result safely

Encoding is the easy direction. Grab the output, drop it into an API example or a test fixture or a quick data URI, done. Decoding is where I slow way down. Glance at the issue list before you trust the text preview, because what falls out could be JSON, a credential, raw binary, or some app-specific format that only looks like garbage. Smells like a JWT segment? Run the whole token through a real JWT decoder instead, this tool only shows you one piece. And if it turns out to be a secret, scrub it before it lands in a screenshot or a Slack thread. I've watched live tokens leak that exact way, more than once.

• Standard Base64 sticks to letters, numbers, plus, slash, plus the optional equals padding tacked on the end.
• Base64URL swaps plus and slash for dash and underscore. That's the one you want anywhere a URL or a token is in play.
• Padding trips people up constantly. Some decoders flat-out demand it. Loads of URL-safe token formats drop it completely.
• Data URI output is great for a tiny inline example. For anything you'd call a real asset, it's a bad idea.
• Byte view is the tab I open when the decoded output isn't readable UTF-8 and I need the actual hex in front of me.

Common Base64 debugging examples

Here's where it earns its keep for me. Webhook drops a Base64 payload? Decode it, see whether you're holding JSON or plain text or binary. API wants Basic Auth? Encode your test username:password string and keep the real secret out of the logs. Token segment full of dashes and underscores? Flip to URL-safe mode, or the decode just falls over. And the data URI that stubbornly won't render. Nine times out of ten it's the MIME type being wrong, or a copy step quietly mangling the padding on you. Maybe it's just me, but that last one has eaten more of my afternoons than I'd like to admit.

Frequently asked questions

Is Base64 encryption?

No. Let me be blunt about it. Base64 is encoding. No secret key lives anywhere in the process, so it protects precisely nothing about your content.

Why does Base64 sometimes end with equals signs?

Padding. That's all they are. Their job is rounding the output up to a clean four-character block. Plenty of URL-safe formats strip them off to save a couple of bytes, then quietly bolt them back on at decode time.

Can I encode files?

Yep. Small ones. The file gets read right here in your browser and turned into Base64, so nothing uploads anywhere. For anything genuinely large, a command-line tool beats sitting around waiting on a textarea.

What is URL-safe Base64?

Same idea, two troublemakers swapped out: + becomes - and / becomes _. Why bother? Because those two characters already mean something in URLs and file names. The variant keeps your encoded string from breaking the moment it lands in one.