Free Base64 Encoder & Decoder
Encode or decode text and files to/from Base64 instantly — with optional URL-safe variant for JWTs and OAuth, file upload for embedding images as data URLs, and live conversion as you type. Everything runs in your browser; nothing is ever uploaded. Built by Datastrive, a Chicago managed IT and cybersecurity provider.
- Bidirectional in one view
- File upload (up to 5 MB)
- URL-safe variant supported
What Base64 actually is — and isn’t
Base64 is an encoding scheme (not encryption) that represents binary data using only 64 ASCII characters: A–Z, a–z, 0–9, plus + and /, with = for padding. It exists because plenty of older systems — email, URLs, JSON, XML attributes — can only safely transmit text, not arbitrary binary bytes.
- Base64 is encoding, not encryption “Decoding” is just reversing the encoding — no key, no secret, anyone can do it. If you’re storing passwords, API keys, or anything sensitive, Base64 provides exactly zero security. It’s only useful for safely transmitting binary data through text-only channels.
- Output is roughly 33% larger than input Base64 encodes 3 bytes of input as 4 characters of output. A 1 MB file becomes about 1.37 MB encoded. That’s why you don’t Base64-encode large files just because you can — embedding a 500 KB JPEG in HTML as a data URL means transmitting 670 KB of base64 every page load.
-
Standard vs URL-safe variants are not interchangeable
Standard Base64 uses
+,/, and=— all of which have special meaning in URLs and JWT tokens. URL-safe Base64 (RFC 4648 §5, often called “base64url”) substitutes-and_and strips the=padding. JWTs, OAuth state parameters, and most modern API tokens use URL-safe encoding. Standard Base64 will fail to decode if a system expects URL-safe. -
Padding (
=) is informational, not strictly required Base64 output is padded with=to a multiple of 4 characters. Most decoders work fine without it; some strict ones reject unpadded input. Always pad when generating, but be lenient when accepting (the “robustness principle”). The strip-padding option above is for systems like JWT that explicitly require unpadded output. -
Watch out for non-ASCII characters in text input
The original Base64 spec was for binary, but most tools also accept text. JavaScript’s built-in
btoa()only handles Latin-1; emoji, Chinese characters, and many Unicode characters need UTF-8 encoding first. This tool encodes text as UTF-8 before Base64-ing, so emoji and international characters round-trip correctly. Other tools may not. -
Embedding files as data URLs has tradeoffs
A data URL like
data:image/png;base64,iVBORw0KGgo...embeds binary directly in HTML or CSS. It eliminates the HTTP request, which speeds up rendering of small assets — favicons, tiny SVG icons, sub-1 KB images. But it also disables browser caching of that asset and inflates page weight. Useful for small, single-use assets; avoid for anything reusable.
Frequently asked questions
What is Base64 used for?
Most common uses: embedding images in HTML or CSS as data URLs, encoding email attachments (MIME), encoding HTTP Basic Auth credentials, encoding the parts of a JWT (JSON Web Token), encoding OAuth state parameters, encoding binary data in JSON or XML, and storing arbitrary binary blobs in text-only databases or config files.
What it’s not used for: encryption, compression, hashing, or any kind of security control. Base64 is purely about safe transmission of binary through text-only channels.
What’s the difference between Base64 and base64url?
The character set differs in two characters:
Standard Base64 uses + and / and pads with =. These three characters all have special meaning in URLs (+ means space, / is a path separator, = is a query parameter assignment), so passing standard Base64 in a URL requires URL-encoding it on top — doubling the encoding overhead and looking ugly.
URL-safe Base64 (base64url) uses - and _ instead, and typically strips the = padding. Used by JWTs, JSON Web Encryption, OAuth, and most modern web tokens. The two encodings are not interchangeable — if you need URL-safe, the toggle above produces it.
Why is Base64 output larger than the input?
Base64 represents 3 input bytes (24 bits) as 4 output characters (each character carries 6 bits of data, so 24 bits total). That’s a 4:3 ratio — output is approximately 33% larger than input.
For very small inputs, the overhead can be more than 33% because of padding. Encoding a single byte produces 4 output characters: 2 data characters plus 2 padding = characters, giving a 400% size increase.
Is my data sent anywhere when I use this tool?
No. The encoding and decoding both happen entirely in your browser using JavaScript. Nothing is uploaded, transmitted, logged, or stored on any server. You can verify this by opening your browser’s Network tab in dev tools while using the tool — you’ll see no outgoing requests during conversion.
This matters because Base64 is often used with sensitive data: API tokens, internal config, JWTs containing user info, etc. Tools that send your input to a server “for processing” are a privacy hole.
Can I encode files larger than 5 MB?
Not with this tool, by design. Browser-based Base64 encoding of large files locks up the UI thread and can crash the tab on lower-end devices. The 5 MB limit keeps the tool responsive for the cases it’s actually useful for — embedding small images, encoding short binary payloads, decoding API responses.
For larger files, use command-line tools: base64 input.bin > output.txt on Linux/macOS, or certutil -encode input.bin output.txt on Windows. These handle arbitrary file sizes without the browser bottleneck.
Why does my decoded output look like garbage characters?
The original data was probably binary, not text — an image, PDF, encrypted blob, or serialized object. Base64 doesn’t carry a content type with it, so once decoded, the bytes are just bytes. When those bytes don’t form valid UTF-8 text, browsers substitute the Unicode replacement character (�) for every invalid byte sequence, which looks like a row of question-mark diamonds.
This tool detects that case automatically: when the decoded bytes aren’t valid UTF-8 text, it shows a hex preview instead of garbage and offers a Download button so you can save the bytes as the actual file. It also tries to identify the format from magic bytes (PNG, JPEG, PDF, ZIP, gzip, etc.) so the download gets the right extension.
If you’re sure the input should be text but you’re still seeing replacement characters, copy-paste sometimes introduces invisible whitespace or zero-width characters that survive the strip step. Try re-copying the source.
Does this work with JWTs?
Yes — enable both “URL-safe” and “Strip padding” toggles. JWTs are three Base64URL-encoded segments separated by dots: header, payload, signature. To decode a JWT, copy each segment between the dots into the input box separately and decode them with URL-safe mode on.
If you specifically want a JWT decoder that splits the segments and shows the parsed JSON, that’s coming as a separate tool. This Base64 tool handles the underlying encoding correctly but doesn’t know about JWT structure.
Need real infrastructure work?
Datastrive runs IT, networking, and security for businesses across the Chicago area. If you’re using Base64 because you’re debugging something more complex than a quick conversion, that’s our job too.
Talk to Datastrive →