To encode or decode Base64 online for free, open the Base64 Encoder/Decoder, paste your text to encode it or paste Base64 to decode it back — the tool is UTF-8 safe, so accents and emoji survive the round trip — and you can also turn a whole file into Base64 text or rebuild a file from Base64 byte for byte, with every step processed on your device only.
Base64 looks like secrecy and is not. It is an encoding — a public, reversible way of writing binary data using only ordinary text characters — invented so that files and bytes can travel through systems that were built for text: email, JSON, web pages, configuration files. Anyone who receives Base64 can decode it instantly with free tools, including this one. Understanding that single fact prevents the most serious Base64 mistake there is, which is treating encoded text as protected text. This guide explains how the encoding works, why it inflates size by about a third, when the URL-safe variant is required, and how the file tools handle the jobs that text pasting cannot.
Encoding Is Not Encryption: Say It Once, Remember It Always
Encryption scrambles data so that only someone holding a key can read it. Encoding merely rewrites data in a different alphabet so that it survives transport. Base64 belongs firmly in the second group: there is no key, no password and no secrecy, and decoding needs nothing but the encoded text itself. An encoded password, token or personal record is exactly as exposed as the original — it simply looks less recognisable at a glance, which makes the risk worse, not better, because people paste encoded secrets into tickets, chats and screenshots believing them safe. If something must be hidden, it needs encryption or a proper hash for the right job, applied by tools designed for that purpose. If something merely needs to travel through a text-only channel intact, Base64 is the right and honest tool.
How Base64 Works, and Why It Costs a Third More Space
The rule is fixed by the format itself, defined in RFC 4648. Base64 takes the input three bytes at a time and writes those three bytes as four characters drawn from a 64-character alphabet of letters, digits and two symbols. Three bytes become four characters, every time, so the output is four-thirds the size of the input — about a third larger — with padding characters (=) added at the end when needed so the total length lands on a multiple of four. That is the whole mechanism, and it makes size calculations exact rather than estimated: multiply any file size by 4, divide by 3, and you have the size of its Base64 text, before any line breaks a particular system might add for display.
How Base64 grows a file: encoded text size for stated original sizes (exact thirds) — hover or tap each bar for details.
Every bar in the chart is that one rule applied to a stated size, with no rounding surprises: 30 KB × 4/3 = 40 KB, 90 KB × 4/3 = 120 KB, 300 KB × 4/3 = 400 KB, and 900 KB × 4/3 = 1,200 KB. The practical consequences show up in real work. An image embedded directly in a page or an email as Base64 adds roughly a third to the transfer compared with the file itself. An API with a payload limit reaches that limit sooner when attachments travel encoded. And a database field sized for a file may overflow when the same file is stored as text. None of this makes Base64 a bad choice — often it is the only choice a text channel offers — but it should always be a chosen cost, never a surprise.
A Worked Example You Can Check Character by Character
The tool's own page gives a compact test that also proves the UTF-8 handling: the text Asad ✓ encodes to QXNhZCDinJM=. The checkmark is the interesting character. It is not in the plain English alphabet, so a careless encoder built only for simple ASCII text would mangle or drop it; a UTF-8 safe encoder first writes the text as UTF-8 bytes — the tick becomes three bytes — and then encodes those bytes, which is why the result decodes back to exactly "Asad ✓", tick intact. Try the same round trip with accented names, Arabic or Urdu text, or an emoji: encode, decode, and compare, and the characters return unchanged. The second worked example is the size one from the tool page: a 90 KB logo becomes about 120 KB of Base64 text, because 90 × 4 ÷ 3 = 120. If a system quotes you a very different figure for a stated file, one of the two numbers is wrong, and this arithmetic is how you find out which.
Test the round trip before trusting any encoded payload: decode what you just encoded and compare it with the original — text should match character for character, and a rebuilt file should match in size. Thirty seconds of checking catches truncated pastes, stray spaces and wrong-variant mix-ups while they are still free to fix.
Text, Files, and the URL-Safe Variant
The tool covers three jobs that are often confused with one another. Text encode and decode handle the everyday pasted string — a value from a config file, an encoded header, a snippet from documentation. File to Base64 reads a file on your device and produces its encoded text, which you can copy or download as a .txt file; that is the route for embedding a small asset or sending a file through a text-only channel. Base64 to file runs the other way: paste the encoded text, give the result a name plus its extension, and the tool rebuilds the original file byte for byte — the extension matters, because Base64 itself carries no file name or type, so a rebuilt image named without .png or .jpg will not open as an image. Files are processed on-device only, in every direction; nothing is uploaded to be encoded or rebuilt.
| Job | Input | Output | Watch out for |
|---|---|---|---|
| Encode text | Typed or pasted text | Base64 string to copy | UTF-8 text is safe here — accents and emoji survive |
| Decode text | Pasted Base64 | The original readable text | Stray spaces or a truncated paste break the decode |
| File to Base64 | A file from your device | Encoded text, copied or saved as .txt | Output is about a third larger than the file |
| Base64 to file | Pasted Base64 plus a file name and extension | The rebuilt file, byte for byte | The extension is yours to supply — Base64 stores none |
| URL-safe encoding | Data destined for a URL | Base64 with - and _ instead of + and /, padding dropped | Standard and URL-safe forms are not interchangeable everywhere |
The URL-safe variant deserves its own paragraph because it causes quiet, confusing failures. Standard Base64 uses + and / among its characters, and both of those mean something special inside a URL — a plus is read as a space in query strings, and a slash is a path separator. So when encoded data must travel inside a link, a token or a file name, the URL-safe variant swaps + for - and / for _, and drops the = padding at the end. The data is the same; the alphabet is road-legal for URLs. Decoding trouble usually traces back to a variant mix-up: standard text fed to a strict URL-safe decoder, or the reverse. When a decode fails on text that looks correct, checking which variant produced it is the first diagnostic step, ahead of assuming the data is corrupt.
Where You Will Actually Meet Base64
Email attachments are the oldest everyday encounter: mail was a text system, so attachments still travel encoded, which is one reason a 10 MB attachment behaves like a noticeably larger message. Images embedded directly in web pages or HTML email — data URIs — are Base64 sitting in the markup, chosen so a small graphic needs no separate file request. Tokens and API payloads carry encoded segments that developers decode to inspect during debugging. Certificates, keys and configuration bundles are frequently distributed as encoded text because text is easy to paste, store and transmit without corruption. In each case the pattern is identical: bytes needed a text-safe ride. Recognising that pattern tells you both what you are looking at — a long, even-looking string, often ending in one or two = signs — and what to do with it: decode to inspect, never to "unlock", because there was never a lock.
Five Base64 Mistakes That Cause Real Damage
- Treating Base64 as encryption. The costliest error on this list. Encoded passwords, tokens and personal data are fully readable by anyone; encoding hides nothing from anyone.
- Forgetting the third-extra size. Embedding or sending encoded files without the × 4/3 calculation leads to bloated pages, oversized emails and payload-limit failures that look mysterious until someone does the arithmetic.
- Mixing the standard and URL-safe variants. Plus and slash characters break inside URLs; the URL-safe alphabet exists precisely for that setting, and the two forms must not be swapped carelessly.
- Rebuilding a file without its extension. Base64 carries bytes, not names or types. A rebuilt file needs the correct name plus extension from you before any program will open it properly.
- Pasting a truncated string and blaming the data. A missing tail — often lost to a careless copy or a line-length limit — fails the decode. Copy the whole string, padding included where the variant uses it, and test the round trip.
Related Tools and Guides
Base64 sits in a family of everyday conversions, and its closest neighbours solve the adjacent problems. When the text travelling is a link rather than a payload, the URL Encoder/Decoder handles percent-encoding, the URL world's own version of this job. When the question is not "rewrite this readably" but "fingerprint this so changes show", the Hash Generator produces one-way digests that cannot be decoded back at all. The encoder itself is the Base64 Encoder/Decoder. For the fuller story on the URL side — plus signs, %20 and double-encoding traps — read our guide to how to encode and decode URLs.
Wrestling with encoded payloads, tokens or file handling inside your own web project? Book a free consultation with Asad Webs
Frequently Asked Questions
Is Base64 a form of encryption?
No. Base64 is an encoding — a public, reversible rewriting of data into text-safe characters. Anyone can decode it instantly with free tools and no key. Never use it to hide passwords, tokens or personal data.
Why is Base64 output bigger than the original file?
By design. Base64 writes every 3 bytes as 4 characters (RFC 4648), with padding to a multiple of four, so output is four-thirds the input size — about a third larger. A 90 KB file becomes about 120 KB of text: 90 × 4/3 = 120.
Does the tool handle accents, Arabic text and emoji correctly?
Yes. Text encoding and decoding is UTF-8 safe, so non-English characters are first written as UTF-8 bytes and survive the round trip intact. The page's own example: 'Asad ✓' encodes to QXNhZCDinJM= and decodes back exactly.
What is the URL-safe variant, and when do I need it?
It replaces + with - and / with _ and drops the padding, because + and / have special meanings inside URLs. Use it whenever encoded data travels inside a link, token or file name; the underlying data is identical.
Can I turn a file into Base64 and back again?
Yes, both ways. File to Base64 gives you copyable text or a .txt download; Base64 to file rebuilds the original byte for byte once you supply a file name and extension — Base64 itself stores neither.
Are my files uploaded to a server for encoding?
No. Files and text are processed on your device only. That matters for the same reason the encoding warning matters: payloads often contain sensitive material, and on-device processing removes the upload from the equation entirely.
Why does my Base64 fail to decode?
The usual causes are a truncated paste, stray spaces introduced by line wrapping, or a variant mix-up between standard and URL-safe alphabets. Copy the complete string, check which variant produced it, and test by re-encoding the decoded result.
Be the first to share a useful question or thought.