An API returns iVBORw0KGgoAAAANSUhEUg...and you need to know it's a PNG (it is — those characters are the Base64 of the PNG magic number). A JWT payload reads as gibberish but contains eyJ... prefixes that are just Base64-encoded JSON. A webhook signs its body with base64url(hmac(secret, body)) and you need to verify the digest in staging. This encoder/decoder handles all three: paste, get the round-tripped result, copy. Full UTF-8 support, both standard and URL-safe alphabets.
Base64 is binary-to-text encoding — it makes arbitrary bytes safe to transmit over text-only channels (email MIME, JSON strings, URL query params, HTTP headers). The trade-off: every 3 bytes of input become 4 ASCII characters out, inflating size by ~33%. The sections below cover the variants you'll encounter and the failure modes that bite in production.
How to Use
- Select mode — Encode or Decode tab.
- Enter data— Paste text or a Base64 string. Load a file directly if you're working with binary.
- Get result — Output appears instantly. Copy or download with one click.
Standard Base64 vs URL-safe variant
Standard Base64 (RFC 4648 §4) uses A-Z a-z 0-9 + / as its alphabet, with = for padding. The + and / characters need percent-encoding in URLs, and the trailing =trips up some routers that strip it. URL-safe Base64 (RFC 4648 §5, also called "base64url") swaps those for - and _, and many implementations drop the = padding entirely. JWT, JWE, JWK, and most webhook signature schemes use base64url, not standard Base64. Mixing them silently produces wrong decoded bytes.
Size overhead and the 33% rule
| Input | Base64 output | Overhead |
|---|
| 3 bytes | 4 chars | +33% |
| 1 KB | ~1.37 KB (with padding) | +33% + 0-3 bytes pad |
| 100 KB image | ~137 KB | +33% |
| 1 MB file | ~1.37 MB | +33% — avoid for large payloads |
Plus padding: input length must be a multiple of 3 bytes; otherwise 1 or 2 = characters are appended. The output length is always a multiple of 4.
When to (and not to) inline images as data URIs
A Base64 data URI (data:image/png;base64,iVBORw0...) embeds an image directly in HTML/CSS, eliminating the extra HTTP request. Use for: small icons (<2 KB), email templates (CIDs are unreliable), single-use inline SVG/PNG, anything that needs to render before network arrives. Avoid for: anything >5 KB (the 33% bloat ruins cache efficiency and the data URI can't be cached separately), repeated images (each occurrence is a fresh copy in the document), and content that needs to be lazy-loaded.
Common pitfalls
- Confusing encoding with encryption.Base64 is reversible by anyone — paste any base64url JWT into a decoder and you see the payload in plain JSON. It's a transport encoding, not a secret.
- Padding mismatch. Some decoders insist on trailing
= padding; others reject it. base64url commonly strips padding, so add it back (= or ==) to reach a length multiple of 4 before decoding with strict parsers. - UTF-8 corruption.
btoa()in JavaScript only handles Latin-1 bytes — "안녕" throws an error. Use btoa(unescape(encodeURIComponent(str))) or the modern TextEncoder + Uint8Array approach. - Line wrapping. Classic MIME Base64 wraps at 76 columns; modern API Base64 is a single line. A decoder expecting wrapped input may reject single-line content, and vice versa.
- Double encoding. Encoding an already-Base64 string produces valid but nonsense output. Always know your starting point.
Frequently Asked Questions
Q: What is the difference between Base64 encoding and encryption?
Base64 is a reversible transformation that converts binary data to text — anyone can decode it without a key. It provides zero security. Encryption (AES, ChaCha20) transforms data using a secret key so only key-holders can recover the original. Treat any Base64-encoded blob as fully readable until it's wrapped in real encryption.
Q: Does Base64 encoding increase data size?
Yes — by about 33% (every 3 bytes become 4 ASCII characters), plus 0-3 bytes of = padding. A 100 KB image becomes ~137 KB Base64. The overhead is the price of making binary data safe for text-only channels; avoid it for large payloads where you can use multipart uploads instead.
Q: What's the difference between standard Base64 and base64url?
Standard Base64 uses + and /, which need percent-encoding in URLs. base64url swaps those for - and _ and commonly drops = padding. JWT, OAuth state params, and most webhook signatures use base64url. Decoding a base64url string with a standard Base64 decoder produces wrong bytes silently.
Q: When should I use Base64 data URIs for images?
For small icons (<2 KB) where eliminating the HTTP round-trip outweighs the 33% bloat, for email templates where image CIDs are unreliable, and for anything that must render before the network arrives. Skip data URIs for images >5 KB, anything reused across the site (cache misses every time), or content that benefits from lazy loading.
Q: Is there a size limit for encoding or decoding?
All processing happens in your browser, so the practical limit is your device's available memory. Most modern browsers handle several megabytes without issue; very large files (50 MB+) may freeze the tab while the editor re-renders. For multi-GB binary data, use server-side streaming Base64 encoders instead.