Base64 Decode Error? Fix Invalid Strings, Padding and URL-Safe

The short answer

An "Invalid Base64 string" error means the text contains something that standard Base64 does not allow, or its length cannot be valid. The usual fixes are: delete everything before the comma in a data: prefix, remove surrounding quotes, replace URL-safe characters (- becomes +, _ becomes /), and remove extra = signs at the end. Paste the cleaned string into the Base64 Encoder/Decoder in Decode from Base64 mode and the text appears immediately.

What a valid Base64 string looks like

Standard Base64 uses only 64 characters plus padding:

• Capital letters A to Z
• Small letters a to z
• Digits 0 to 9
• + and /
• = only at the very end, as padding

Every 3 bytes of data become 4 Base64 characters. When the data does not divide evenly into 3 bytes, one or two = signs pad the last group. For example, "Hello World" encodes to SGVsbG8gV29ybGQ=, with one =.

How the decoder handles common problems

These results come from the Lazyblink decoder, which uses the browser's standard Base64 decoding:

Input	Result	Why
SGVsbG8gV29ybGQ=	Hello World	Valid string
SGVsbG8gV29ybGQ	Hello World	Missing padding is accepted
SGVsbG8 gV29y bGQ=	Hello World	Spaces and line breaks are ignored
SGVsbG8gV29ybGQ==	Error	One = too many
PDw_Pz8-Pg==	Error	URL-safe - and _ characters
data:text/plain;base64,SGVsbG8=	Error	The prefix contains :, ; and ,
"SGVsbG8="	Error	Quotation marks are not Base64
a	Error	A single leftover character can never be valid

So spaces, line breaks and missing padding are forgiven, but extra padding and any character outside the Base64 alphabet are not.

Fix 1: Remove a data URI prefix

Images and files embedded in HTML or CSS often look like this: data:image/png;base64,iVBORw0KGgo.... Only the part after the comma is Base64. Delete everything up to and including the comma, then decode.

Note that the Lazyblink decoder shows the result as text. If the data is an image, PDF or other binary file, the decoded output will look like random symbols because it is not text. That does not mean the Base64 is wrong. To create a data URI from an image, use the Image to Base64 tool.

Fix 2: Convert URL-safe Base64 (Base64url)

Some systems use a URL-safe variant, called Base64url, because + and / have special meanings in web addresses. It swaps two characters and often drops the padding:

Standard Base64	Base64url
+	-
/	_
= padding	Usually removed

For example, the text <<???>> is PDw/Pz8+Pg== in standard Base64 and PDw_Pz8-Pg in Base64url.

To decode Base64url in a standard decoder, replace every - with + and every _ with /. You do not need to add the padding back, because missing padding is accepted. The Find and Replace tool makes the swap quick for long strings.

You will meet Base64url in JSON Web Tokens (JWTs), some API keys and signed URLs. For JWTs specifically, the JWT Decoder handles the URL-safe format for you and splits the token into its header and payload.

Fix 3: Fix the padding

Base64 length follows a pattern. After removing spaces, a valid string has a length that is a multiple of 4 (with padding), or leaves a remainder of 2 or 3 (without padding). A remainder of 1 is always invalid.

• Too many = signs. There can be at most two. If the string ends with == and still fails, try removing one =.
• A remainder of 1 character. Part of the string is missing or something extra was added. Copy it again from the source; it was probably cut off or joined with another value.

Fix 4: Remove quotes, escapes and stray characters

When you copy Base64 out of JSON, code or a log file, extra characters often come with it:

• Surrounding quotation marks: "SGVsbG8="
• A trailing comma or semicolon from JSON or code
• Escaped slashes, such as \/ instead of / in some JSON output. Replace \/ with /.
• Line-ending markers like \n written out as text (real line breaks are fine; the two characters backslash and n are not)
• A full stop at the end of a sentence in an email or chat

Delete these and decode again.

Fix 5: The output is garbled but no error appears

If decoding works but the text looks wrong, the bytes are being interpreted in a different character encoding from the one used to create them.

• The Lazyblink decoder reads the result as UTF-8 first, which covers English, Hindi, emoji and most modern text. w6k= decodes to é and 8J+Yig== decodes to 😊.
• If the bytes are not valid UTF-8, it falls back to reading each byte as a single character. Older Latin-1 text still comes out readable this way: 6Q== decodes to é.
• Text in other legacy encodings may still look garbled. In that case the Base64 is fine; the original text was in an encoding the decoder does not detect.

If the output is a mix of symbols with odd characters such as PNG or PDF near the start, you are probably decoding a binary file, not text.

Why your Base64 does not match someone else's

When you encode the same message in two places and get different Base64, the input was almost always slightly different:

• A hidden newline. Hi encodes to SGk=, but Hi followed by a newline encodes to SGkK. On Mac and Linux, echo Hi | base64 adds that newline; use echo -n Hi | base64 to match the tool.
• Trailing spaces copied with the text.
• Different characters that look the same, such as a curly quote versus a straight quote.

The encoder uses UTF-8 for all text, so नमस्ते becomes 4KSo4KSu4KS44KWN4KSk4KWH. Another tool using a different encoding would produce a different result.

Quick checklist

Remove any data:..., prefix.

Remove quotes, commas, semicolons and escaped slashes.

Replace - with + and _ with / if the string is URL-safe.

Make sure there are no more than two = at the end.

Decode. If the result is symbols, the data may be a binary file rather than text.

Base64 is an encoding, not encryption. Anyone can decode it, so never treat a Base64 string as a way to hide passwords or keys. If you need to protect text, use proper encryption, such as a password-protected file or an encrypted messaging app. For background on how the format works, read what Base64 encoding is.