data:image/png;base64,... — the prefix is detected and stripped for you. Decoded images are previewed inline; binary data gets a download button. Everything runs locally in your browser and nothing is uploaded.data: URI into the decode box — the prefix is stripped automatically, and line breaks and spaces are ignored.-_) and missing = padding are handled automatically — no manual fixing needed.No — and this is the single most important thing on the page. Base64 is encoding: it re-expresses arbitrary binary data using 64 printable characters (A-Z a-z 0-9 + /). There is no key and no secret; the rules are public and anyone can reverse it in one step. It solves "this channel only carries text and I need to push an image through it", not "I need to make this unreadable". So Base64-ing a password, an ID number or an API key before storing it in a database or embedding it in front-end code provides no protection whatsoever. If you genuinely need something irreversible, see SHA-256 Hash Generator; to store passwords, use a slow hash such as bcrypt.
These links look like data:text/html;charset=utf-8;base64,PGh0bWw+... and typically come from the share feature in QQ Mail and some forums. They fail to open not because the link is broken: since 2017 Chrome has blocked top-level data: navigation, with Firefox and Edge following suit, because the feature was heavily abused for phishing — an entire fake login page fits inside one link, and the address bar cannot show a real domain for it.
The content is still in the link. Paste the entire link (including the data:text/html;charset=utf-8;base64, prefix) into the decode box above and this page will detect the prefix, strip it, and decode the rest. If the result is HTML, you will see the full page source.One word of caution before you look: if the link came from a stranger, there is a fair chance it is a phishing page. Decoding it to read the content is fine — just never fill in the account and password fields it contains.
Mostly embedding: writing a small icon straight into CSS as background-image: url(data:image/png;base64,...) or into HTML as <img src> saves one HTTP request; it is also how you get an image into JSON, Markdown or an email body, none of which carry anything but text. The cost is about 33% more bytes (every 3 bytes become 4 characters), and an embedded image cannot be cached separately by the browser — change one byte and the whole CSS file's cache is invalidated. So it only suits icons of a few KB; photos and large images belong behind a URL. Tick "Add the data URI prefix" above to get a complete string you can paste straight into code.
That is the URL-safe variant (RFC 4648 §5). In the standard alphabet, + and / have special meanings in URLs and filenames and get escaped or truncated inside a query parameter, so they are replaced with - and _; the trailing = padding is equally awkward in a URL and is usually dropped. This is exactly how the three segments of a JWT are encoded. This page recognises both forms when decoding, so you never have to substitute characters by hand; tick "URL-safe alphabet" to produce this form when encoding.
There is no encryption in Base64, so there is nothing to decrypt — the correct word is Decode, and it always succeeds. Switch to decode mode above, paste, click, and you have the original. This is completely unlike MD5 or SHA-256, which are one-way hashes: those are irreversible, whereas Base64 is a fully reversible two-way encoding. If you find someone using Base64 to "encrypt" sensitive data, that is a security problem, not an encryption scheme.
Read the notice first. After decoding, this page tries to read the bytes as UTF-8; if that fails, the content was never text — it is an image, a PDF or an archive. The page then names the format it sniffed and offers a download button; downloading is the right move, and forcing it on screen will of course look like garbage. If you are certain it should be text and it still looks wrong, the original was probably encoded in something other than UTF-8, such as GBK. This page always decodes as UTF-8, so that case needs a tool where you can pick the character set.
Three common causes. One: a few characters were lost while copying, leaving a length that is not a multiple of four and cannot be padded. Two: characters outside the Base64 alphabet crept in — copying from a chat log often drags along curly quotes or an ellipsis. Three: the string is actually URL encoding (%3Chtml%3E ) rather than Base64. Line breaks and spaces never cause this error; the page ignores them automatically.
Base64 represents 3 bytes with 4 characters, so it always inflates to 4/3 of the original — about 33% more — plus the padding at the end. This follows from how the encoding works and is identical in every Base64 tool; it is not something this page does. If size matters, compress before encoding, or skip embedding and reference a URL instead.
Encoding is capped at 10 MB. That limit is not a technical ceiling but a point past which the exercise stops making sense: Base64 exists to embed data in text, and a 10 MB file becomes a 13 MB string that will cause trouble wherever you paste it. Decoding has no hard limit, but browsers slow down on very long strings, so an input of tens of MB may stutter.
No. URL encoding (percent-encoding) only replaces characters that are special in a URL with %XX, leaving everything else as-is, so the result stays roughly readable. Base64 re-expresses All of the content using 64 characters: entirely unreadable, but able to carry arbitrary binary safely. The two often appear together — when you put standard-alphabet Base64 into a URL parameter, the + and / inside it still need URL encoding on top. That is precisely why the URL-safe variant exists.
Yes, but mind the character set. Base64 operates on bytes, not characters, so the text must first be turned into bytes by some encoding. This page always uses UTF-8, which is the current norm. The same Chinese text encoded as GBK and then Base64-ed gives a completely different result, so when two tools disagree, check the character set before suspecting the Base64 implementation.
No. Conversion uses the browser's built-in atob / btoa and FileReader: the file is read into memory, converted and displayed, and not one byte leaves your device. Disconnect from the network once the page has loaded and the tool still works — that is the quickest way to verify it. See the Privacy Policy.