Base64 Encoder/Decoder
Base64 turns any data — text, images, files — into a string of plain ASCII characters, so binary content can travel safely through text-only channels like JSON, URLs, HTML, and email. This free Base64 encoder/decoder converts in both directions with correct UTF-8 handling, offers the URL-safe variant, and can turn a file into a data URL. Everything runs 100% in your browser: your data is never uploaded anywhere.
100% client-side — your data never leaves this browser.
What Base64 is
Base64 represents binary data using 64 characters: A–Z, a–z, 0–9, +, and /, with = as padding. It works by regrouping bits:
| Step | What happens |
|---|---|
| 1. Group | Input bytes are taken 3 at a time (24 bits) |
| 2. Split | The 24 bits are split into 4 groups of 6 bits |
| 3. Map | Each 6-bit group becomes one of the 64 characters |
| 4. Pad | = fills the output to a multiple of 4 characters |
So the text Man (3 bytes) becomes TWFu (4 characters) — and any 3 bytes, text or not, become 4 characters the same way. When the input length isn't a multiple of 3 bytes, = padding fills the gap: Ma becomes TWE= and M becomes TQ==. Decoding is the exact reverse — regroup the characters into 6-bit chunks, map them back to bytes, and strip the padding. That's also why damaged Base64 (a dropped character or a stray space) fails loudly instead of decoding to garbage: the math stops adding up.
Common use cases
- Embedding images in HTML/CSS — small images become
data:URLs, cutting HTTP requests. - API payloads — sending binary data inside JSON, which can't carry raw bytes.
- Email attachments — MIME encodes attachments in Base64 for the same reason.
- HTTP Basic Auth — the
username:passwordpair in the Authorization header is Base64-encoded. - JWTs — tokens use the URL-safe Base64 variant for their header and payload segments.
How to use it
- Choose Encode or Decode, and Standard or URL-safe.
- Type or paste your text — conversion is live as you type.
- To encode a file instead, pick it with the file input; images show a preview.
- Copy the output with the copy button.
Base64 is not encryption
This trips people up regularly: Base64 looks scrambled, but it's trivially reversible by design — there is no key and no secret. Encoding a password or API key in Base64 hides it from no one; it's roughly as protective as writing it upside down. Use real encryption (or a secrets manager) for anything sensitive, and treat Base64 as what it is: a transport format for getting binary data through text-only systems.
Standard vs URL-safe
Standard Base64's + and / characters are meaningful inside URLs (+ can mean "space" in query strings, / separates paths), and = padding can confuse parsers. The URL-safe variant swaps + → - and / → _ and usually drops padding. Rule of thumb: standard for email, MIME, and data URLs; URL-safe for anything that ends up in a URL, filename, or token.
Encoding files and images
Picking a file produces a data URL: data:[mime-type];base64,.... Browsers can use these directly as image sources or download links, which is handy for tiny icons and one-off HTML emails. Two caveats: the ~33% size overhead applies to files too, so don't data-URL large images; and some email clients and older systems cap data-URL length, so test before relying on them in production mail.
Frequently asked questions
- Is Base64 encryption?
- No. Base64 is an encoding, not encryption — it just represents binary data with printable characters, and anyone can reverse it instantly. Never use Base64 to "protect" passwords, tokens, or personal data; it provides zero secrecy.
- Why is Base64 output longer than the input?
- Every 3 input bytes become 4 output characters, so encoded data is about 33% larger (plus padding). That overhead is the price of representing arbitrary bytes with only 64 safe characters.
- What's the difference between standard and URL-safe Base64?
- Standard Base64 uses + and / with = padding; URL-safe replaces them with - and _ and usually drops the padding, because + and / have special meanings in URLs and filenames. Use URL-safe whenever the output goes into a URL, filename, or JWT.
- Does this handle emoji and non-English text correctly?
- Yes. The text is first converted to UTF-8 bytes and those bytes are encoded, which is the correct behavior. Naive tools that feed characters straight into btoa() corrupt anything outside basic ASCII — emoji included.
- Can I encode an image or another file?
- Yes — pick a file and it's converted to a data URL (for example, data:image/png;base64,iVBOR...). Images also show a preview so you can confirm the right file was encoded. Everything happens locally in your browser.
- Is my data uploaded anywhere?
- No. Encoding, decoding, and file conversion all run entirely in your browser. Nothing is sent to any server, so you can safely encode tokens, config snippets, or images containing private content.
- How do I decode a data URL?
- Strip the prefix first — everything up to and including the comma (data:image/png;base64,) — then decode the remaining Base64 part. Decoding the full data URL including the prefix will fail, which is why this tool rejects input with a data-URL prefix.