Base64 to Text
Paste a Base64 string and get the original human-readable text back instantly, decoded entirely on your device with zero uploads.
What it does
- Decode standard Base64 and URL-safe Base64URL
- Read JWT payloads, secrets, and config values privately
- Choose the output character set for non-UTF-8 sources
- Runs in WebAssembly, nothing leaves the tab
Base64 to text decoding takes an encoded string (a config value, a JWT payload, an API response field, an email or MIME chunk, an environment variable, or a copied secret) and returns the original human-readable text, all decoded locally in your browser with no upload and no server round trip. Paste, decode, and copy in one step. Because Base64 so often carries security-sensitive material, this tool runs entirely on your device so the bytes never travel anywhere.
What this conversion actually does (and does NOT do)
Base64 is a binary-to-text encoding built from the alphabet A-Z, a-z, 0-9, +, and /. It is not encryption. It provides zero confidentiality, and anyone can decode it in seconds, so it must never be relied on to hide data. Decoding it simply reverses the transformation back into the original bytes.
Decoding always produces raw bytes first. Turning those bytes into readable text requires knowing the character set the source used. Defaulting to UTF-8 when the original was UTF-16, ISO-2022-JP, or Shift-JIS is the single most common cause of garbled or garbage output. If the underlying bytes are themselves binary (an image, a gzipped blob, a certificate in DER form) rather than a string, no character set will render readable text, and that is a reliable signal the source was never text to begin with.
There are two flavors to watch for. Standard Base64 uses + and / with = padding. Base64URL, used in JWTs and inside URLs, swaps those for - and _ and often drops the trailing padding entirely. A standard-only decoder fails on JWT segments unless it auto-detects the URL-safe alphabet, which this tool does. On the size side, encoding inflates data by roughly 33% (four output characters for every three input bytes), plus about 4% more when line breaks are inserted, so the decoded text comes out around 25% smaller than the Base64 string you pasted.
What it does NOT do is repair genuinely corrupt input. Incomplete final blocks need = padding to decode, and missing padding, extra padding, stray whitespace, or non-alphabet characters cause failures. You cannot fix truly broken Base64 by blindly stripping characters, because that changes the byte boundaries and shifts every value after the edit.
When to choose Base64 to text vs Base64 to a file
Decode to text when the original payload was a string: JWT claims, JSON or YAML config, env vars, MIME-encoded email bodies, or PEM-wrapped certificate text. If the decoded output looks like binary noise instead of words, the source was almost certainly a file (an image, an archive, or a binary certificate), and you should treat the result as bytes to save rather than text to read. JWTs are a special case worth knowing: they are three Base64URL segments (header.payload.signature) joined by dots, and decoding the middle segment reveals the claims in plaintext, which is exactly why JWT payloads should never carry secrets or PII. To go the other direction, use text to Base64 encoding.
How to convert Base64 to text
- Open this page, which is locked to decode mode (Base64 to text) so you cannot accidentally re-encode.
- Pick the variant if needed: leave it on standard Base64, or switch to URL-safe Base64URL for JWT segments and URL parameters.
- Paste your Base64 string into the input field.
- Click convert to decode the string into readable text.
- Copy the result, or download it as a file.
No upload. It runs on your device.
This decoder is compiled from Rust to WebAssembly and runs inside your browser tab. There are zero network requests for the decode itself: your Base64 string is processed in memory and never sent anywhere. It works offline once the page has loaded, there is nothing to log, and nothing to delete because nothing was ever uploaded. You can confirm it yourself by opening the DevTools Network tab and watching it stay silent while you decode. This matters because Base64 disproportionately carries JWT claims, API secrets, credentials, environment variables, and customer PII, and pasting that kind of material into a server-side tool is a genuine exposure risk.
No limits
No sign-up, no ads, no watermark, and no caps on how much you decode. Paste a single token or a long multi-line block as often as you like.
Frequently asked questions
- Is it safe to decode a JWT or secret in this Base64 decoder?
- Yes. The decode runs entirely in your browser via Rust compiled to WebAssembly, so JWT segments, tokens, and secrets never leave your machine and are never sent to a server. Security guidance specifically warns that not all online decoders run client-side, so for sensitive payloads a verifiable local tool removes the exposure risk.
- Does this tool upload my Base64 data to a server?
- No. There are zero network requests for the decoding step, and you can verify this in the DevTools Network tab while you work. The page even functions offline after it loads, which is only possible because all processing happens on your device.
- Why does my decoded Base64 show garbage or weird characters?
- Decoding produces raw bytes, and rendering them as text requires the correct character set. The usual culprit is assuming UTF-8 when the source was UTF-16, ISO-2022-JP, or Shift-JIS, which produces mojibake; switching the output character set typically fixes it.
- How do I fix "invalid Base64" or padding errors?
- Incomplete final blocks require
=padding, so check that the string was not truncated and that stray whitespace or non-alphabet characters were not pasted in. Note that you cannot repair genuinely corrupt Base64 by stripping invalid characters, because that shifts the byte boundaries and corrupts everything after the edit. - What is the difference between Base64 and Base64URL, and can this decode JWT tokens?
- Standard Base64 uses
+and/with=padding, while Base64URL swaps those for-and_and often drops padding. This tool handles the URL-safe alphabet, so you can decode the individual dot-separated segments of a JWT to read its header and claims. - Is Base64 encryption? Is decoded data secure?
- No, Base64 is an encoding, not encryption, and it offers zero confidentiality. Anyone can decode it instantly, so it must never be used to hide data, and any secret stored only as Base64 should be treated as plaintext.
- How do I decode multiple Base64 lines at once?
- It depends on whether the lines form one value or several. A single value split across lines (like a PEM certificate or a wrapped MIME body) should be decoded as one block, while several independent values each need decoding separately, so handle them according to which case you have.
- Why is my decoded output binary or unreadable instead of text?
- If the decoded bytes are binary, such as an image or a gzipped blob, no character set will turn them into readable text. That is a clear signal the original source was a binary file rather than a string, so save the output as a file instead of trying to read it.
- Can I decode Base64 offline or without an internet connection?
- Yes. Once the page has loaded, the WebAssembly decoder runs fully on your device, so you can disconnect and keep decoding. This is also why nothing is ever logged or stored: the work happens locally.
Need the reverse direction or related tools? Use text to Base64 encoding to go back the other way, reach for the combined Base64 encoder and decoder when you switch directions often, or browse the full text and data tools hub for JSON, CSV, YAML, and more.