Base64 Encoder and Decoder

Encode, decode and inspect Base64, Base64URL and data URIs, all in your browser.

This Base64 encoder and decoder lets you encode, decode and inspect Base64 without anything leaving your browser. We built it to do more than convert a string. Encode text or a small local file, decode standard or URL-safe Base64 back to bytes, and read the padding, the byte count, the decoded UTF-8 and an optional data URI. It handles the plus, slash, dash and underscore alphabets along with the equals padding that breaks so many decoders, and it shows a hex byte preview when the output is not readable text. For example, paste a token full of dashes, switch to URL-safe, and you get clean bytes back. One thing we keep in view: Base64 is encoding, not encryption, so it hides nothing. Everything runs in your browser, so nothing you paste is uploaded.

100% in your browser. Nothing you type ever leaves this page.

Local Base64, Base64URL and data URI workbench

This Base64 encoder and decoder converts and inspects Base64 right in your browser, which is the job most people land here to do. Paste text or drop a small file to encode, or paste standard or URL-safe Base64 to get the bytes back. We show you the padding, the byte count, the decoded UTF-8, and a data URI when you ask for one, plus a raw hex byte view when the output is not readable text. One point we keep returning to, because it is the one that bites in production: Base64 is encoding, not encryption. It hides nothing. Everything runs in your browser, so nothing you paste is uploaded.

Mode

Variant

Padding

Data URI MIME

Optional local file

Input

Everything runs in your browser, text and files both. Don't mistake Base64 for secrecy. And keep live credentials or production tokens out of any screenshot you're about to share.

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.