Online Base64 Decoder Tool

1. 1

   Paste the Base64

   Drop the string into the input box. Line breaks, missing padding and base64url characters are all handled, and a data URI, PEM block or JWT can be pasted whole — the wrapper is detected and stripped for you.

2. 2

   Read the result

   Output appears as you type for anything up to 256 KB; larger input decodes when you press Decode. The panel names the variant it found, the file type it recognised in the decoded bytes, and the character set it used to render text.

3. 3

   Adjust if the guess was wrong

   Switch the view between text, hex and printable ASCII, pick a specific character set if the auto-detected one produced replacement characters, or turn on strict mode to have malformed input refused rather than repaired.

4. 4

   Copy or download

   Copy the text, or download the payload under the extension its own bytes say it should have — a decoded PNG saves as .png, not as .bin. Everything is processed on your device and nothing is uploaded.

Five settings, and each of them exists because a real payload needed it. Nothing here is gated behind a paid plan — a decoder that withholds the decode is not limited, it is broken.

Input format

Leave this on Auto and paste anything. The tool checks, in order, for a data URI prefix, an OpenPGP armour block, a PEM header, and a three-part JWT, and falls back to treating the input as a bare payload. Choosing a format explicitly turns it into an assertion: if you pick PEM and the input has no BEGIN line, you get told so rather than getting a decode of something else. Picking Standard or URL-safe additionally pins the alphabet, so with strict mode on a payload using the other one is refused at the exact character where it diverges.

Strict mode

Off by default, because the everyday task is reading a string somebody sent you and refusing it over a missing = helps nobody. Turned on, four things become errors instead of repairs: whitespace outside a wrapped format, absent or wrong padding, a mixed alphabet, and a final group whose unused bits are not zero. That last one is worth knowing about — it is described in its own section below, and no other decoder on the web reports it.

Split input

One mechanism, two uses. Each line decodes a list of independent payloads separately and shows them as separate results, which is what you want when a log file or a database column has one Base64 value per line. JWT segments splits at the dots instead, so the header and the payload of a token each decode on their own and a signature that is not readable text does not spoil the rest. Auto picks the second when the input is a JWT and leaves everything else alone.

Show result as

Auto shows text for a text payload and a hex dump for anything else, based on what the bytes actually are rather than on whether a text decoder produced something. You can override it: hex is the right view for a binary payload you are inspecting, printable ASCII is useful for spotting embedded strings inside a binary, and forcing Text is how you check a payload the detector called wrong. Switching views is instant because it re-renders bytes that have already been decoded.

Character set

Auto reads a byte-order mark first, then any charset declared by a data URI, then tests whether the bytes are valid UTF-8, and falls back to Windows-1252 as a labelled guess. If the result has replacement characters in it, the panel says how many, and picking the right set from the list fixes it without re-decoding the Base64.

Base64 is one encoding, but it arrives wrapped in at least seven different things. A decoder that only accepts a bare payload rejects most of what people actually have in their clipboard.

• Standard — the RFC 4648 alphabet — A–Z, a–z, 0–9, + and /, padded with =. What most encoders emit.
• URL-safe (base64url) — the same, with - and _ in place of + and /, so the string survives being put in a URL or a filename. Usually unpadded. Detected and decoded without a setting.
• MIME — standard Base64 wrapped at 76 columns, as email bodies use. The line breaks are stripped; in strict mode they are the one whitespace that stays legal, because the format is defined by them.
• PEM — a payload between -----BEGIN X----- and -----END X----- lines, as certificates, private keys and CSRs use. The labels must match at both ends, and a block whose BEGIN and END disagree is reported as damaged rather than quietly decoded.
• OpenPGP ASCII-Armor — PEM's cousin, with optional armour headers and a =CRC24 checksum line. The checksum is verified — it is the only integrity check any Base64 variant carries, and a tool that strips it without looking has thrown away the one piece of evidence the format offers.
• Data URI — data:image/png;base64,…, which is what copying an inline image out of CSS or developer tools gives you. The prefix is removed, and its declared media type and charset are used rather than guessed at.
• JWT — three base64url segments separated by dots. Split at the dots so the header and payload each decode as the JSON they are — including tokens with an empty signature segment, which alg:none produces and which a stricter split would refuse.

This is the part most Base64 decoders skip, and skipping it is why so many of them hand you a screen of question marks. Base64 says nothing about its contents. Once the bytes exist, though, they usually say so themselves: almost every binary format begins with a signature, and reading it is cheap.

Around forty signatures are checked, covering images (PNG, JPEG, GIF, WebP, BMP, ICO, TIFF, AVIF, HEIC), documents (PDF, RTF), archives (ZIP, gzip, bzip2, xz, zstd, 7z, RAR), audio and video (MP3, FLAC, Ogg, WAV, MP4, WebM, AVI), fonts (TTF, OTF, WOFF, WOFF2) and executables. ZIP-based formats are refined a step further by reading the name of the first entry inside the archive, so a decoded .docx is offered as a .docx rather than as a .zip, and an OpenDocument file is identified from the media type its own mimetype entry carries. When nothing matches, the bytes are tested for being text at all — a NUL byte is the signal, with an exception for UTF-16, which is half NUL bytes by construction — and text that starts with a brace is only labelled JSON if it actually parses.

Two things follow from this that you can see in the interface. The download button offers the file under the extension its own bytes justify, so a decoded PNG saves as .png and opens on a double click. And a binary payload is never run through a text decoder to produce a page of U+FFFD replacement characters — it goes straight to the hex view, and the panel says what it found.

This is the single most common reason a decode 'looks wrong', and it is not a bug in the decoder. Base64 encodes bytes. It carries no field for an encoding, no header, and no convention for one. Any tool that shows you text has chosen an encoding on your behalf, and most of them do not tell you which.

• A byte-order mark is a statement — if the decoded bytes begin with a BOM, the producer has said what the encoding is, and that is used. UTF-8, UTF-16 in both byte orders and UTF-32 in both are recognised.
• A data URI can declare one — data:text/plain;charset=windows-1251;base64,… names its own charset, and it is honoured — but it ranks below a BOM, because a BOM is in the data and the parameter is only a claim about it.
• Valid UTF-8 is near-proof — UTF-8 has enough structure that a document of any length being valid is very unlikely by chance. If the bytes decode strictly as UTF-8, that is what they are.
• Pure ASCII proves nothing — ASCII is valid UTF-8 and valid in every single-byte set, so the question does not have an answer. The tool says 'ambiguous' rather than claiming a confident detection the data cannot support.
• Otherwise it is a guess, and is labelled one — a payload that is not valid UTF-8 is some single-byte encoding, and the bytes cannot say which. Windows-1252 is the most common by a wide margin, so it is the fallback — shown as a guess, with the full list one click away.

Thirty-one character sets are offered, and the list is built by asking the browser which ones it actually supports rather than by listing the ones it is supposed to. UTF-32 is the exception: no browser implements it in its text decoder, so it is decoded here directly, which is why it appears in the list at all.

Base64 packs three bytes into four characters. When the input length is not a multiple of three, the final group is short — and some of the bits in its last character do not belong to any byte.

In a two-character final group, the last four bits are spare. In a three-character group, the last two are. A conforming encoder writes zeros there. Nothing requires a decoder to check, and so essentially none do: QQ== and QR== both decode to the single byte 0x41, silently, in every browser, in every command-line tool, and on every website we tested. One of those strings came from an encoder and the other was corrupted or hand-edited, and no tool tells them apart.

Strict mode checks. It is reported as an error when strict mode is on and as a warning when it is off, so the bytes are still there to look at — the point is not to refuse the data, it is that you should know the string was not produced the way it claims to have been. The same applies to a payload that mixes the two alphabets: - and _ never collide with + and /, so it decodes unambiguously, but one of the two is out of place and somebody should probably know.

Every refusal names the character index, the line and the column of the problem, and what the character was. Neither of the browser's own Base64 functions reports a position, and nor does any competing tool — on a four-megabyte payload with one stray character, 'invalid' is not a diagnosis.

• Not valid Base64 — a character outside the alphabet. In lenient mode this is only reported for characters that are genuinely foreign — spaces and line breaks are stripped first. A non-breaking space, which is what copying from a rendered web page often produces, counts as foreign, and the position tells you exactly where it landed.
• Truncated — the payload has a final group of one character, which no amount of input can produce. This is the one unambiguous 'the string was cut short' signal Base64 has.
• Data after padding — there are characters after the = signs. Almost always two Base64 strings that have been joined together, which every lenient decoder will happily turn into plausible garbage.
• Missing or unexpected padding — strict mode only. The = characters are absent, too many, or not the length the payload's own length requires.
• Whitespace not allowed — strict mode only, and only outside the wrapped formats. Line breaks inside MIME, PEM and PGP are part of those formats and stay legal.
• Wrong or mixed alphabet — strict mode only. The payload uses characters from the alphabet you did not select, or from both.

Base64 is an encoding, not encryption and not a safety boundary. It is used to move bytes through channels that only accept text, and the bytes on the other side are whatever somebody put there.

• Decoded output is untrusted input — a payload can decode to a script, an executable, or markup designed to run somewhere else. Nothing about having been Base64 makes it safe, and the fact that it arrived encoded is sometimes the point.
• Do not paste secrets you would not paste elsewhere — this page runs entirely on your device and sends nothing anywhere, which you can verify with your browser's network tools — but the habit of pasting credentials into web forms is worth not building, because most pages that look like this one do upload.
• A JWT's payload is not verified — splitting a token and decoding its segments shows you what it claims. It does not check the signature, and anyone can produce a token that says anything. Read it as a claim, never as a fact.
• An armour checksum is not a signature — the CRC-24 in a PGP block catches accidental corruption. It is not a cryptographic check and it does not tell you who produced the block.

Base64 does not only arrive on a clipboard. It is saved into .txt and .b64 files, into .pem certificates and .asc armour blocks, and embedded in .json, .xml and .eml documents — so all of those can be dropped onto the page.

What Free includes

Up to 25 MB of Base64, one input at a time, and every capability the tool has: all seven input formats, all thirty-one character sets, strict mode, the hex and ASCII views, the file-type detection, the typed download and the split modes. The cap is on scale, never on whether the tool works — 25 MB of Base64 is about 18.75 MB of decoded data, which is a large payload by any normal measure.

What Pro adds

Up to twenty inputs at a time, all of them downloadable as a single archive, and the size cap replaced by whatever your device can actually handle rather than a bigger fixed number. Compression in the archive is chosen per file from what the payload turned out to be, so a batch of decoded images is stored rather than pointlessly re-compressed, while a batch of decoded JSON is deflated.

Several encodings look enough like Base64 to be mistaken for it, and a decoder that accepts them anyway produces convincing nonsense. If the output is garbage and the character set is not the problem, check whether the input is one of these.

• Percent-encoding — %20 and %E2%9C%93 are URL encoding, not Base64. Use the URL encoder and decoder instead.
• Hexadecimal — a string of only 0–9 and a–f, with an even length, is far more likely to be hex than Base64 — and hex is valid Base64 too, which is exactly why the mistake produces a decode rather than an error.
• Base32 — uppercase A–Z and 2–7, padded with =. It shares the padding character and nothing else.
• A hash — an MD5, SHA-1 or SHA-256 digest is not encoded data and cannot be decoded back into anything. It is a one-way fingerprint; use the hash generator to produce one.
• Already-decoded text — ordinary English words are made of Base64 characters, so a sentence pasted into a decoder will 'decode' into bytes. If the result is binary and the input was readable, the input was not encoded.

Reach for the decoder when you already have a Base64 string and need what is inside it. Use the encoder for the opposite direction.

• Inspecting a Base64 field in an API response, a webhook body or a log line.
• Reading the header and payload of a JWT to see what a token claims.
• Pulling an image or font out of a data URI embedded in CSS, HTML or an SVG.
• Checking what a PEM certificate or a PGP armour block actually contains.
• Recovering text stored as Base64 in a database column or a .env file.
• Confirming that an encoder somewhere produced conforming output, using strict mode.
• Turning a Base64 payload back into a real, openable file with the right extension.

The decoder uses whichever Base64 path your browser provides — the newest browsers have a native one, and older ones fall back to a route that is present everywhere and produces byte-identical output. There is no configuration and nothing to install. Character sets come from the browser, so the exact list varies very slightly between engines; the tool shows what yours actually supports rather than what it is meant to.

Decoding runs off the main thread on your device, using the fastest Base64 path your browser provides. Measured on a desktop machine, a 25 MB payload decodes in about 170 milliseconds end to end, including working out what the bytes are.

• Base64 Encoder
• Base64 Encoder/Decoder
• URL Encoder/Decoder
• Hash Generator
• UUID Generator
• QR Code Reader
• JSON Formatter
• JSON Validator
• JSON Minifier
• XML to JSON
• Case Converter
• Text Trimmer
• Color Converter
• All converters