If you've ever pasted a long string of random-looking characters into a terminal, an API request, or a CSS file — chances are you were dealing with Base64. It's one of those things developers use constantly without thinking about it much, until something breaks.
Base64 is a way to represent binary data (like images, files, or anything non-text) using only plain ASCII characters. The name comes from the 64-character alphabet it uses: A-Z, a-z, 0-9, +, and /, with = for padding.
The reason it exists is simple: a lot of systems — email, JSON, URLs, HTML attributes — were built to handle text, not raw bytes. When you need to shove a PNG into a JSON payload or embed a font in a stylesheet, Base64 gives you a text-safe way to do it.
A quick example
Encoding the string Hello World gives you SGVsbG8gV29ybGQ=. That trailing = is padding — Base64 works in chunks of 3 bytes, and when the input doesn't divide evenly, it pads the output.
You can try it right now in your browser console:
btoa('Hello World') // "SGVsbG8gV29ybGQ="
atob('SGVsbG8gV29ybGQ=') // "Hello World"Where you'll run into Base64
Here are some of the places Base64 shows up in everyday development work:
- Data URLs — Embedding small images or icons directly into HTML or CSS with
data:image/png;base64,...to save an extra HTTP request. - API payloads — Some APIs expect file uploads, signatures, or binary data sent as Base64-encoded strings inside JSON bodies.
- Email attachments — MIME encoding has used Base64 since the early days of email. Every attachment you've ever sent was Base64 under the hood.
- JWTs — JSON Web Tokens encode their header and payload as Base64url (a URL-safe variant). You've probably decoded a JWT to debug auth issues at some point.
- Certificates — PEM files (the ones that start with
-----BEGIN CERTIFICATE-----) are just Base64-encoded DER data.
The 33% size increase — and why it usually doesn't matter
The most common criticism of Base64 is that it makes data bigger. And it's true — encoding adds roughly 33% overhead because you're using 4 characters to represent every 3 bytes. A 30KB image becomes about 40KB in Base64.
For small assets (icons, tiny logos, placeholder images under 5KB), the tradeoff is often worth it. You eliminate an HTTP request, which can matter more than a few extra kilobytes, especially on high-latency connections. But for anything larger — a product photo, a PDF, a video — just use a normal file URL. There's no benefit to Base64-encoding a 2MB image.
Common mistakes that trip people up
After seeing developers run into the same issues repeatedly, here are the ones worth knowing about:
- Forgetting the MIME prefix — If you're using Base64 in an
<img>tag or CSSurl(), you need the full data URL:data:image/png;base64,iVBOR.... Just the encoded string won't render anything. - Whitespace in the string — Copy-pasting Base64 from emails or formatted text often introduces line breaks. Most decoders handle this, but some strict parsers will choke on it.
- Assuming decoded output is always text — Not every Base64 string decodes to something you can read. If the original was a JPEG or a ZIP file, you'll get binary garbage in a text editor. That's expected.
- Using Base64 for "encryption" — This comes up more than you'd think. Base64 is encoding, not encryption. Anyone can decode it instantly. It provides zero security.
About this tool
Everything runs in your browser. Your text, files, and encoded output never hit a server — there's no backend processing involved at all. This makes it safe to use with API keys, tokens, certificates, or any other sensitive data you'd rather not paste into a random website.
You can encode plain text, upload files (images, documents, whatever) and get the Base64 output with the correct MIME type, or paste a Base64 string and decode it back. If the decoded content is an image, you'll get a preview. If it's binary, you can download it directly.