Base64 Encoder & Decoder

Paste the Base64 string into the input box and the decoded result appears in the same tab immediately — no button, no account and no upload. If the string lives in a file you can open a .txt or .b64 file instead of pasting. The decoder reads both the standard (+ /) and the URL-safe (- _) alphabet, silently skips the line breaks, tabs and spaces that came along with the paste, and shows the decoded byte length beside the result.

Switch to the encode side, paste your text or pick a .txt file, and the Base64 output appears with canonical padding by default. Your text is turned into UTF-8 bytes first, so accented letters, CJK characters and emoji survive a round trip unchanged. You can select the URL-safe alphabet when the result has to sit inside a URL or a filename, or switch padding off when the receiving system expects an unpadded string; copy and download always take the full output, not the shortened on-screen preview.

No — the string you paste never leaves the tab, because decoding runs entirely inside the page you already loaded and makes no network request. That matters for the Base64 blobs people usually decode: session tokens, log fragments, configuration secrets and mail attachments that you are often not allowed to paste into a remote service at all.

Yes, once the page has loaded you can disconnect the network and keep decoding and encoding, because nothing is fetched while a string is decoded. An air-gapped laptop behaves exactly like a connected one. The only thing that needs the network is loading the page in the first place, so keep the tab open if you know the connection is about to go away.

Open the page in Edge, Chrome or Firefox on Windows 11 and paste the string — no software is installed and no PowerShell command is needed. It is usually quicker than certutil -decode, which insists on a file on disk and a temporary path, and unlike the command line it points at the exact character position when the string turns out to be malformed instead of just failing.

It means a character outside both Base64 alphabets appeared in the payload, and the message names that character together with its exact index, line and column. The position refers to the string exactly as you pasted it, so it can be highlighted rather than hunted for. The usual culprits are a curly quotation mark copied out of JSON, an ellipsis from a truncated log line, or a stray angle bracket from surrounding XML.

Because the decoded bytes are not valid UTF-8 or carry control bytes that no text file would contain, so they are reported as binary instead of mojibake. The check is strict and never substitutes replacement characters: you get an honest verdict plus the byte offset of the first broken sequence. If the bytes start with a known image signature — PNG, JPEG, GIF, WebP, BMP, TIFF or ICO — the container is named and the payload is offered as a download.

The input is capped at 2,000,000 characters and the decoded payload at 2,000,000 bytes, and both ceilings are checked before any memory is allocated. An oversized paste is therefore refused instantly with a size error that reports the counts and the limit rather than freezing the tab while it allocates a buffer it cannot fill. Long text results are shown up to 200,000 characters on screen, while copy and download still carry the whole payload.

Yes — a string whose length leaves a remainder of two or three characters decodes normally and is simply flagged with a note that the padding was absent. Unpadded Base64 is the norm in JWTs and URL parameters, so treating it as an error would be wrong. What is rejected is padding that is wrong rather than missing: too many = signs, a partial pad, data appearing after the padding, or a length remainder of one character, which cannot come from any complete byte.

Decoding is safe here because the payload is only ever treated as inert bytes: nothing is executed, no decoded HTML is rendered and no URL inside it is fetched. The risk moves to what you do next — a decoded installer or a macro-bearing document is exactly as dangerous once you save and open it as it was inside the message. This tool tells you what the bytes are; it does not scan them for malware.

Standard Base64 uses + and / for the values 62 and 63, while URL-safe Base64 uses - and _ so the string can sit inside a URL or a filename untouched. Both decode to identical bytes, and this tool accepts either one and tells you which it detected. A string that mixes the two is refused, because that combination almost always means two different strings were spliced together during copy-paste.

No — a clean decode proves only that the characters formed a well-formed Base64 sequence, not that the data is authentic or that nobody altered it. Base64 is an encoding, not encryption and not a signature: anyone can modify a payload, re-encode it, and it will decode just as cleanly. Judge the content on where it came from, not on the fact that it decoded.

Yes — the data: prefix is recognised, stripped and reported back with the media type it declares, and only the part after the comma is decoded. That keeps the prefix out of the byte count and out of the download. A data: URL without the ;base64 marker is refused instead of being decoded anyway, because a percent-encoded data: URL is a different format and reading it as Base64 would produce nonsense.