Base64 decode to text

Base64 decode any RFC 4648 base64 string and get the original UTF-8 text back. Whitespace and line breaks inside the input are stripped before decoding, so wrapped MIME blocks and pretty-printed tokens both work. Invalid input returns [invalid base64] rather than throwing. The transform runs in your browser; nothing uploads.

Input
Line 1:1 LF cloud_done Saved locally
Result Base64 Decode
0 lines 0 chars

Base64 decoding, whitespace tolerant

Base64 decoding reverses the four-character-per-three-byte packing back into the original byte stream. The standard alphabet is A-Z a-z 0-9 + / with = padding. TextResult decodes the cleaned input via atob, then walks the resulting byte stream as UTF-8 so multibyte characters reassemble correctly. Y2Fmw6k= decodes the bytes 63 61 66 C3 A9, which is the UTF-8 encoding of café.

Whitespace is forgiving. Spaces, tabs, line feeds, and carriage returns are stripped before decoding, so a 76-character-wrapped MIME block, a multi-line PEM body, or a token someone pasted with stray newlines all work. The standard padding rule is enforced: the input length (after whitespace removal) must be a multiple of 4, with at most two trailing =.

If the cleaned input contains characters outside the alphabet, or has the wrong padding, the tool returns [invalid base64] and shows it in the output panel. URL-safe base64 (- and _ instead of + and /) is not auto-translated. To decode JWT tokens, use JWT decoder, which understands the URL-safe variant. For URL-encoded text, see URL decode.

How to use base64 decode to text

  1. 1Paste your base64 string into the input panel on the left.
  2. 2The decoded text appears in the output panel on the right as you type.
  3. 3Whitespace and line breaks inside the input are ignored, so wrapped MIME blocks work as-is.
  4. 4Click Copy in the output header to copy the decoded text.
  5. 5If the result reads [invalid base64], check for stray characters or missing padding.

Keyboard shortcuts

Drive TextResult without touching the mouse.

Shortcut Action
Ctrl FOpen the find & replace panel inside the input Plus
Ctrl ZUndo the last input change
Ctrl Shift ZRedo
Ctrl Shift EnterToggle fullscreen focus on the editor Plus
EscClose find & replace, or exit fullscreen
Ctrl KOpen the command palette to jump to any tool Plus
Ctrl SSave current workflow draft Plus
Ctrl PRun a saved workflow Plus

What this tool actually does

Standard RFC 4648 alphabet only

Accepts A-Z a-z 0-9 + / with = padding. URL-safe base64 (- and _ in place of + and /) is not auto-translated; replace them yourself or use JWT decoder for JWT segments.

Whitespace stripping before decode

A regex strips every \s character (spaces, tabs, newlines, carriage returns) before decoding. Wrapped MIME bodies, PEM blocks, and copy-paste tokens with stray breaks decode without manual cleanup.

UTF-8 reassembly of multibyte characters

After atob, the byte stream is interpreted as UTF-8 via decodeURIComponent(escape(...)). So w6k= reassembles to é and four-byte emoji like 🙂 roundtrip cleanly.

Graceful failure for bad input

Invalid characters, wrong padding, or a length that is not a multiple of 4 returns [invalid base64] instead of throwing. The status bar at the bottom of the input shows the byte length so you can spot truncation.

Browser-side, no upload

Decoding runs through the native atob on each keystroke. No server round-trip, no log of what you pasted. Safe for tokens, API responses, and credentials.

Worked example

The trailing == is the standard 1-byte-remainder padding, the embedded 0x0A reassembles as a newline, and the bytes C3 A9 roundtrip back to é.

Input
SGVsbG8sIHdvcmxkIQpDYWbDqQ==
Output
Hello, world!
Café

Settings reference

Behaviour Effect on output
Standard alphabet input Decoded to UTF-8 bytes via atob, then reassembled as a string.
Whitespace inside input Stripped before decoding. Spaces, tabs, \n, and \r are all ignored.
Padding = Required when input length is not a multiple of 4 by itself. Up to two trailing = are accepted.
URL-safe characters - and _ are not auto-translated. The decoder treats them as invalid.
Invalid input Returns the literal string [invalid base64] in the output panel.
Multibyte characters Reassembled as UTF-8. Accents, emoji, and CJK roundtrip if they were UTF-8 encoded before the original base64 step.
Empty input Returns an empty string.

FAQ

Why does my JWT segment return [invalid base64]?
JWTs use URL-safe base64 with - and _ instead of + and /, and they often omit padding. Use JWT decoder, which handles both variants and splits the three segments for you.
Can it handle line-wrapped input from a MIME or PEM block?
Yes. Whitespace and line breaks inside the input are stripped before decoding, so a 64- or 76-character-wrapped block decodes the same as the unwrapped form. The PEM -----BEGIN----- / -----END----- markers are not stripped, so paste only the base64 body.
What happens if the padding is wrong?
The decoder returns [invalid base64]. Standard base64 needs the input length (after whitespace removal) to be a multiple of 4, padded with = as required. Add the missing = characters and re-paste.
Does it support accented characters and emoji?
Yes, when the original encoder used UTF-8. The decoded byte stream is reassembled as UTF-8, so café, こんにちは, and 🙂 all roundtrip if they were UTF-8 encoded going in.
Is the input sent anywhere?
No. Decoding runs entirely in your browser via the native atob function. Nothing is uploaded, nothing is logged.