Base64 Encoding Explained — Encode and Decode Free Online
You've seen those long strings starting with data:image/png;base64, in HTML, or a JWT made of garbled-looking text, or an email attachment that's somehow stored as plain characters. That's Base64 at work. It's a simple, clever scheme for carrying binary data through systems that only understand text. This guide explains exactly how Base64 works, why the output grows by about a third, what that trailing = means, and the most important caveat: Base64 is not encryption. You can encode and decode text or files free, right in your browser, with nothing sent to a server.
- Base64 converts binary into 64 safe ASCII characters, defined in RFC 4648, so data survives text-only channels.
- It maps every 3 bytes to 4 characters, which makes the output about 33% larger than the input.
- Base64 is not encryption - it's trivially reversible. Never use it to hide secrets.
- The
=at the end is padding that fills out the final 4-character group when input doesn't divide evenly by 3.
What Is Base64 Encoding?
Base64 is a binary-to-text encoding that represents arbitrary bytes using 64 printable ASCII characters, standardized in RFC 4648. Its purpose is to move binary data safely through channels designed for text, like email and URLs. The alphabet is fixed: A-Z, a-z, 0-9, plus, and slash - exactly 64 symbols, hence the name.
The problem Base64 solves is old but still everywhere. Many systems were built to handle text, not raw bytes. Email, for instance, was originally designed for 7-bit ASCII. Send raw binary through it and bytes get mangled. Base64 sidesteps this by re-expressing the binary using only characters that every text system handles identically.
So Base64 is best understood as packaging, not transformation of meaning. The original data is fully preserved; it's just wrapped in a representation that won't break in transit. Decoding unwraps it back to the exact original bytes. Nothing is lost, nothing is added except the predictable size overhead we'll get to shortly.
How Does Base64 Actually Work?
Base64 takes input three bytes at a time. Three bytes are 24 bits; those 24 bits are regrouped into four 6-bit chunks; each 6-bit chunk (a value from 0 to 63) maps to one character in the 64-symbol alphabet. So every 3 input bytes become exactly 4 output characters, which is the root of the 33% size increase.
Walk through it with the word "Man." Those three letters are the bytes 77, 97, 110. In binary that's 01001101 01100001 01101110, twenty-four bits. Regroup into six-bit pieces: 010011 010110 000101 101110. Those four values are 19, 22, 5, 46, which map to the characters T, W, F, u. So "Man" encodes to TWFu. Tidy, isn't it?
What about padding?
Input rarely divides evenly into groups of three. When the final group has only one or two bytes, Base64 pads the output with one or two = characters so the result still arrives in clean four-character blocks. One leftover byte produces two encoded characters plus ==; two leftover bytes produce three characters plus a single =.
How to Encode and Decode Base64 Online with FusionPDF
The Base64 tool runs entirely in your browser using built-in JavaScript encoding functions. Text and files are converted locally, so your data stays in your browser and is never sent to a server. Encoding a short string is instant; even multi-megabyte files convert in moments, limited only by your device, not by any upload.
Go to fusionpdf.pro/base64. No account, no sign-up. It loads directly in your browser.
Pick encode to turn text or a file into Base64, or decode to turn a Base64 string back into the original text or file.
Paste text, paste a Base64 string, or drop a file onto the page. The conversion happens in browser memory - check your network tab and you'll see no upload request fires.
Copy the encoded or decoded text to your clipboard, or download the decoded file. Everything stayed local from start to finish.
When Should You Use Base64?
Use Base64 whenever binary data has to travel through a text-only channel. The classic cases are data URIs that embed images directly in HTML or CSS, MIME email attachments, and binary values carried inside JSON or XML. The shared thread: the transport accepts text, the data is binary, and Base64 bridges the gap.
Data URIs for inline images
A data URI lets you embed a small image directly in your markup instead of linking to a separate file: data:image/png;base64,iVBORw0.... This saves an HTTP request, which can speed up loading for tiny assets like icons. The trade-off is the 33% size growth and the fact that the browser can't cache the image separately.
Email attachments (MIME)
Email's foundations assume text. When you attach a PDF or photo, the mail client Base64-encodes it so the binary survives the journey, then the recipient's client decodes it back. This happens invisibly on every attachment you've ever sent. It's the original problem Base64 was built for.
Binary inside JSON
JSON has no native binary type. To put an image, a file, or raw bytes inside a JSON field, you Base64-encode them into a string. APIs do this constantly for things like file uploads or embedded thumbnails. The receiving side decodes the string back to bytes.
Rule of thumb on data URIs: in our experience, inlining works well for assets under about 2-4 KB, like small icons or SVGs. Beyond that, the size overhead and the loss of separate caching usually outweigh the saved request. For anything larger, link to a real file.
Why Is Base64 Not Encryption?
Base64 is not encryption because it uses no key and hides nothing - anyone can decode it instantly with a standard function built into every browser and programming language. Encryption requires a secret key and is meant to be unreadable without it. Base64 is a public, reversible mapping. Treating it as security is a recurring, serious mistake.
The confusion is understandable. Base64 output looks scrambled and unreadable to a human, so it feels protected. But "looks random to me" is not security. The decoding rule is published, universal, and built into atob() in your browser. There's no lock to pick because there was never a lock, just a different alphabet.
Never use Base64 to hide secrets. Base64-encoding a password, an API key, or any sensitive value gives zero protection. Anyone who sees the string can decode it in one step. We've seen credentials "obscured" this way in config files and request bodies, and it's no better than writing them in plain text. For secrets, use real encryption or a secrets manager.
So when is the look-scrambled effect actually fine? When you don't need secrecy at all. JWT payloads use Base64url precisely because they're meant to be readable by anyone holding the token; the security comes from a separate signature, not from the encoding. Knowing this distinction cleanly separates "format" from "protection," and that clarity prevents a whole category of bugs.
What Is URL-Safe Base64?
URL-safe Base64 is a variant that replaces the two characters that cause trouble in URLs - + and / - with - and _, and usually drops the = padding. Standard Base64's + and / have special meanings in URLs and filenames, so RFC 4648 defines this alternate alphabet for exactly those contexts.
The reason is purely about where the string travels. In a URL, a + can be interpreted as a space and a / as a path separator, both of which corrupt the data. URL-safe Base64 swaps them for characters that pass through untouched. This is the variant JWTs use, which is why you never see + or / inside a token.
Good to know: the two variants encode the same bytes; only a couple of characters differ. If you decode a JWT segment with a standard decoder and get an error, the - and _ characters are usually why. The FusionPDF Base64 tool handles both. To inspect tokens specifically, see our JWT decoder guide.
Frequently Asked Questions
Is Base64 a form of encryption or security?
No. Base64 is an encoding, not encryption. It uses no key and is trivially reversible with a standard function in any browser or language. The output looks scrambled but offers zero protection - anyone can decode it instantly. Never use Base64 to hide passwords, API keys, or secrets. For real protection, use proper encryption.
Why does Base64 make my text about 33% bigger?
Base64 converts every 3 bytes of input into 4 output characters. That 3-to-4 ratio means the encoded result is roughly one-third larger than the original. The extra size is the cost of representing 8-bit binary using a 6-bit alphabet of safe characters. Padding can add a couple of bytes more. This overhead is expected and unavoidable.
What does the = at the end of Base64 mean?
The = is padding. Base64 works in 3-byte groups producing 4 characters each. When the input length isn't a multiple of 3, the final group is short, so one or two = characters fill it out to a complete 4-character block. One leftover byte gives ==; two leftover bytes give a single =. It carries no data itself.
Can I Base64-encode an image or other file?
Yes. Any file is just bytes, and Base64 encodes arbitrary bytes. Encoding an image produces a long text string you can embed in a data URI, JSON field, or email. Remember the result is about 33% larger than the file. For embedding in HTML or CSS, this works well for small images but is inefficient for large ones, where a normal file link is better.
What's the difference between Base64 and URL-safe Base64?
They encode identical bytes but use slightly different alphabets. Standard Base64 includes + and /, which have special meanings in URLs and filenames. URL-safe Base64 replaces them with - and _ and often drops the = padding, so the string can sit in a URL or filename without being corrupted or needing escaping. JWTs use the URL-safe variant.
Encode or Decode Base64 Now
Free, instant, private. Convert text and files to and from Base64, standard or URL-safe. Your data stays in your browser - no upload, no account.
Open Base64 Tool →