Base64 encoding converts binary data into a 64-character text alphabet (A-Z, a-z, 0-9, plus two symbols) so it can travel safely through systems built for text, like URLs, JSON, email, and CSS. To decode, you reverse the process back to the original bytes. It is an encoding, not encryption: anyone can decode it, so it adds zero security.
The reason base64 exists is simple. Plenty of channels were designed to carry text and choke on raw binary. A JSON string cannot hold arbitrary bytes, an email body historically had to be 7-bit ASCII, and a URL has reserved characters with special meaning. Base64 reshapes any binary blob into safe printable characters, at the cost of making it about 33% larger, because it packs 3 bytes into 4 characters.
How Base64 Encoding Works#
The mechanic is worth understanding once. Base64 takes your bytes 3 at a time. Three bytes are 24 bits, which split evenly into four 6-bit groups. Each 6-bit group (a value from 0 to 63) maps to one character in the base64 alphabet. So every 3 input bytes become exactly 4 output characters.
When the input is not a clean multiple of 3 bytes, the encoder pads the end. One leftover byte produces two characters plus ==; two leftover bytes produce three characters plus =. That trailing = is padding, not data, and it is why base64 strings so often end in one or two equals signs.
Input bytes: M a n
ASCII: 77 97 110
Binary: 01001101 01100001 01101110
6-bit groups: 010011 010110 000101 101110
Base64: T W F u
So Man encodes to TWFu. Decode TWFu and you get Man back, byte for byte. Nothing is lost, because base64 is fully reversible.
The Three Variants That Trip People Up#
Here is the gap most explainers leave open: "base64" is not one fixed format. There are three common variants, and using the wrong one is a frequent source of "it decodes to garbage" bugs.
| Variant | Characters 62 & 63 | Padding | Where you use it |
|---|---|---|---|
| Standard (RFC 4648) | + and / | = padding | JSON, general data, most APIs |
| URL-safe (RFC 4648 §5) | - and _ | often no padding | URLs, filenames, JWT segments |
| MIME (RFC 2045) | + and / | = padding | Email; wraps lines every 76 chars |
The differences matter in practice:
- Standard is the default. It uses
+and/, which are fine inside JSON and most request bodies. - URL-safe swaps
+for-and/for_, because+and/have reserved meanings in a URL (a+can become a space, a/is a path separator). This is the variant JWTs use for their header and payload segments. Padding is often dropped too. - MIME is standard base64, but it inserts a line break every 76 characters so old email systems do not choke on long lines. Feed those embedded newlines to a strict decoder that does not expect them and it may fail.
Tip: if a base64 string decodes to nonsense, check the alphabet first. A
-or_in the data means it is URL-safe and you are decoding it as standard, or vice versa. Mismatched variants are the number one base64 bug.
Inlining Images as Data URLs#
The most practical use of base64 on the web is the data URL: embedding a small file directly inside HTML or CSS instead of linking to it. A data URL has a fixed shape:
data:[<mime-type>][;base64],<encoded-data>
For a tiny PNG icon, the encoded image becomes a string you can drop straight into a CSS background-image:
.icon {
background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...");
width: 16px;
height: 16px;
}
The browser decodes the base64, reconstructs the PNG, and renders it with no separate network request. The same works inline in HTML:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." alt="icon" />
When inlining helps and when it hurts#
This is the judgment call explainers skip. Inlining is not free, because base64 inflates the file by roughly 33% and the inlined bytes cannot be cached separately from the page or stylesheet.
Inline a data URL when:
- The asset is tiny (a small icon, a 1x1 spacer, an SVG under a couple of kilobytes).
- You want to eliminate an extra HTTP request for a critical above-the-fold image.
- The asset is used once and rarely changes.
Link to a normal file instead when:
- The image is large. Base64 bloat plus no separate caching makes the page heavier and slower.
- The asset is reused across many pages, where a cached external file wins easily.
- The image changes often, since an inlined copy invalidates the whole page or stylesheet cache on every change.
The rule of thumb: inline small, one-off, critical assets; link everything else.
Base64 Is Not Encryption#
This trips up beginners constantly, so it is worth stating plainly. Base64 is reversible by anyone with no key and no secret. It obscures nothing. If you base64-encode a password or an API key, you have not protected it; you have just made it slightly less obvious to a human skimming the text. A JWT payload is base64url-encoded, which is exactly why anyone can decode and read its claims without the signing secret.
When you actually need confidentiality, use real encryption. Base64 is for safe transport of bytes through text channels, not for hiding them. For the JWT angle specifically, our guide on decoding versus verifying a JWT safely explains why reading a token is trivial while trusting it requires signature verification.
Encode and Decode Safely in Your Browser#
Like SQL and JWTs, the data you base64-encode is often sensitive: a config file, a private key blob, an internal image. Pasting it into a server-side tool ships those bytes off your machine. A codec that runs entirely in the browser keeps everything local.
Step 1: Encode text or a file#
Open the free base64 encoder and decoder, paste text or drop a file, and pick your variant (standard or URL-safe). For an image, the tool reads the file, encodes the bytes, and builds a ready-to-paste data: URL with the correct MIME type, all in the page, so the file never uploads.
Step 2: Decode and preview the result#
Paste a base64 string to decode it. If it is text, you get the text back. If it is an encoded image, the codec previews the decoded image directly, so you can confirm it is valid instead of staring at a blob. When the input is not printable text, it falls back to a hex dump so you can inspect the raw bytes.
Step 3: Copy the data URL into your CSS or HTML#
Take the generated data:image/...;base64,... string and drop it into a background-image or an <img src>. Reserve this for small, critical assets per the inlining rules above, and link larger or reused images normally.
Quick Reference#
- Base64 maps every 3 bytes to 4 text characters, growing data by about 33%.
- Trailing
=is padding, not data. - Standard uses
+and/; URL-safe uses-and_; MIME wraps lines at 76 characters. - A data URL is
data:<mime>;base64,<data>and inlines an asset with no extra request. - Inline small, one-off assets; link large or reused ones.
- Base64 is encoding, not encryption; it provides no security.
For images specifically, the dedicated image-to-base64 converter builds the data URL with a live preview, and the Molixa base64 codec handles text, files, and the hex-dump fallback for non-text input, entirely client-side.
Frequently Asked Questions#
What is base64 encoding used for? Base64 converts binary data into plain text so it can travel through channels built for text, such as URLs, JSON payloads, email bodies, and CSS data URLs. It lets you embed an image directly in a stylesheet, carry a file inside a JSON field, or pass binary data in a URL parameter without it getting corrupted by reserved characters.
Is base64 encoding secure or encrypted? Neither. Base64 is fully reversible by anyone, with no key and no secret, so it provides zero security. It only reshapes bytes into safe printable characters for transport. Encoding a password or API key in base64 does not protect it. When you need actual confidentiality, use real encryption, not base64.
How do I convert an image to a base64 data URL?
Encode the image bytes to base64, then wrap them as data:image/png;base64,<encoded-data> (swap the MIME type to match the file). Paste that string into a CSS background-image or an HTML <img src> and the browser decodes and renders it with no extra request. A browser-side codec builds the full data URL for you and previews the result.
What is the difference between standard and URL-safe base64?
Standard base64 uses + and / for its last two characters, which is fine in JSON and most APIs. URL-safe base64 replaces them with - and _ because + and / are reserved in URLs, and it often drops the = padding. JWT header and payload segments use the URL-safe variant. Decoding with the wrong alphabet produces garbage.
Why does my base64 string have equals signs at the end?
Those are padding. Base64 works in groups of 3 input bytes producing 4 characters, so when the input length is not a multiple of 3, the encoder appends one or two = characters to fill the final group. One trailing byte yields ==, two trailing bytes yield =. The padding carries no data and some URL-safe encoders omit it.
Should I inline images as base64 or link to files? Inline only small, one-off, critical assets like a tiny icon or an above-the-fold image where saving an HTTP request matters. Base64 inflates size by about 33% and inlined data cannot be cached separately from the page, so for large or frequently reused images, a normal linked file that the browser caches is faster.
