Base64 decoder

Decode Base64 to text in one step

Paste the string into “Your text” and the original text appears in “Result”. SGVsbG8g8J+Riw== decodes to Hello 👋, and Q2Fmw6k= to Café. Line breaks and spaces inside or around the string are ignored, so Base64 copied from an email or a wrapped log line works as is. “Copy result” and “Download TXT” take the decoded text wherever you need it, “Load example” fills in a sample string and “Clear” empties the box.

Standard vs URL-safe Base64, and padding

There are two Base64 alphabets and the decoder takes both, even mixed in one string. Standard Base64 uses + and /, and the URL-safe variant swaps them for - and _ so the string survives inside a link. That's why SGVsbG8g8J+Riw== and SGVsbG8g8J-Riw both decode to Hello 👋. The trailing = is padding that rounds the length up to a multiple of four characters.

• No padding is fine: SGVsbG8 gives Hello, the same as SGVsbG8=, and URL-safe SGk_ gives Hi?, the same as SGk/
• Partial padding fails: SG9sYQ= is rejected, because once = appears the length must be a multiple of 4
• More than two =, or an = in the middle, fails too
• A string with one character too many, like SG9sY, can't be valid Base64

Why a Base64 string won't decode

There are two kinds of failure. If the string has characters outside the Base64 alphabet or an impossible length, you see “Enter valid Base64 text.” If it is valid Base64 but the bytes don't form UTF-8 text, you get a decoding error instead of garbled output. A plain word can trigger the second one: Hola uses only Base64 letters, but its bytes aren't text.

• A data:image/png;base64, prefix: the colon, semicolon and comma aren't Base64
• A whole JWT with its dots: decode each part on its own
• A string copied from a URL with %3D where = should be: change it back to =
• Text that was encoded from Latin-1 or Windows-1252, where é is a single byte (6Q==)
• An image, a PDF or any other file: those bytes aren't text

Reading a JWT payload and other Base64 you'll meet

A typical JWT has three parts separated by dots, and the first two are JSON in URL-safe Base64. Copy only the middle part: eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFuYSIsImFkbWluIjpmYWxzZX0 gives {"sub":"1234","name":"Ana","admin":false}. The third part is the signature, raw bytes, so it fails here. Decoding the payload doesn't check that signature, so it shows what a token claims, not whether the token is genuine. A string that starts with eyJ is almost always encoded JSON.

Base64 shows up wherever bytes have to travel as text: email attachments (wrapped in lines of 76 characters), data: URLs in web pages, config files, API responses and HTTP Basic auth headers, where dXNlcjpwYXNz is user:pass. A string starting with iVBORw0KGgo is a PNG image and one starting with /9j/ is a JPEG. This decoder returns text only, so it won't show them.

Base64 is not encryption

Anyone who has a Base64 string can read it, as you just did. Passwords or personal data stored only as Base64 are in plain sight for whoever opens the file. Decoding doesn't decrypt either: if the data was encrypted before it was encoded, you'll get a decoding error here, and reading it takes the original key and algorithm.

Decoding runs in your browser and the string is never uploaded. Still, think twice before pasting live session tokens or API keys from work into any website: a valid JWT can open an account until it expires, and its payload often carries an email address or a user ID that you may not want to share.