Base64 Decode
Paste a Base64 string to read it, or switch direction to encode. UTF-8 and URL-safe both handled.
About this tool
Base64 exists because a lot of the internet only moves text safely. Email headers, JSON fields, URLs, XML documents and HTML attributes all have characters that mean something structural, and raw binary walking through them gets corrupted. Base64 re-spells any bytes using 64 characters everything agrees on, so an image, a signature or a compressed blob can travel through a text-only channel and come out identical.
The two places it trips people up are both handled here. The first is UTF-8: the browser's built-in btoa only speaks Latin-1, so tools built directly on it break the moment a string contains an accent or a CJK character. The second is the URL-safe alphabet, which replaces + and / with - and _ and drops the trailing padding — the form JWTs use. Paste either variant, padded or not, and it decodes without you having to identify it first.
One thing worth repeating because it causes real incidents: Base64 is not encryption. There is no key. A Base64 string is readable by anyone who bothers to paste it into a page like this one, so it protects nothing — it only makes a value less obvious at a glance. Everything here runs locally, which is exactly why you can paste a token in to inspect it without that inspection becoming its own leak.
Frequently asked questions
Is Base64 encryption?
No, and treating it as such is a genuine security mistake. Base64 is an encoding — a reversible re-spelling of bytes using 64 safe characters, with no key and no secret. Anyone who sees the string can decode it in one step, exactly as this page does. It hides nothing. Passwords, tokens and personal data are no more protected in Base64 than in plain text; encoding them only makes them slightly less obvious to a human skimming a file.
Why do my accented or non-English characters come out broken?
Because many tools use the browser's raw btoa/atob, which only understand Latin-1. Feed btoa a string containing é or 日 and it either throws or mangles the bytes. Encoding has to go through UTF-8 first, which is what happens here — café, 日本語 and 👍 all survive a round trip intact. If another tool gave you garbled output, that is almost always the cause.
What is the URL-safe alphabet?
Standard Base64 uses + and /, both of which mean something else inside a URL, and = which needs escaping in query strings. The URL-safe variant swaps them for - and _ and drops the padding. JWTs use it, as do many APIs. Decoding here accepts either alphabet automatically and re-adds missing padding, so you never have to work out which one you were given.
I decoded something and got a screen of gibberish.
Then the original data was not text. Base64 is often used to carry images, PDFs and archives — a data: URI for a PNG is Base64 — and those bytes have no readable form. The tool detects this and tells you rather than pretending the mess is your answer. To recover an actual file you need to save the decoded bytes with the right extension, which a text box cannot do.
Why did my data get bigger?
Base64 turns every 3 bytes into 4 characters, so encoded output is about 33% larger than the input, plus padding. That is the price of making binary data survive channels that only accept text. It is why inlining large images as data: URIs bloats a stylesheet, and why attachments make emails noticeably heavier than the files themselves.
Does my input get uploaded?
No. Encoding and decoding both run in this page, and no network request is made while you work. Tokens, config values and API responses can be inspected here without sending them to anyone.