"Invalid character" / Invalid Base64 String Error, Explained
Base64 decoders are strict about their alphabet and padding — a string that looks fine to the eye can still fail because of one wrong character or a missing =.
What triggers it
- Wrong alphabet. Standard base64 uses
+and/; URL-safe base64 (used in JWTs and query strings) uses-and_instead. Feeding a URL-safe string to a standard decoder (or vice versa) throws an invalid-character error on the first-or_it hits. - Missing or wrong padding. Standard base64 pads the output to a multiple of 4 characters with
=. A string with the wrong number of padding characters, or padding in the middle instead of the end, fails to decode. URL-safe base64 as used in JWTs typically omits padding entirely — decoders that expect it need to add it back before decoding. - Whitespace or line breaks. Some contexts (email attachments, certain config files) wrap base64 output at a fixed line width. A strict decoder that doesn't strip whitespace first will reject the embedded newlines.
- It's simply not base64. Plain text that happens to contain only letters and numbers can look like base64 but have an invalid length or fail entirely once a non-alphabet character shows up.
How to fix it
Identify which alphabet you actually have — if it contains - or _, treat it as URL-safe base64. Strip surrounding whitespace, and pad the length to a multiple of 4 with = if your decoder requires it. The Base64 Encoder / Decoder handles both alphabets and won't choke on missing padding.
Validate the decoded bytes
Successful decoding does not prove that the input was the expected payload. Base64 can represent arbitrary binary data, not only UTF-8 text. Check the decoded length, file signature, content type, or an expected hash before treating the output as trustworthy. If text contains replacement characters, confirm the producer's character encoding instead of decoding the bytes repeatedly.
When Base64 is transported in a URL or form body, verify whether + was converted to a space. Prefer Base64URL for URL components and avoid logging credentials or tokens merely because they look encoded. Encoding is not encryption, and secrets remain recoverable by anyone who receives the string.
Frequently Asked Questions
How does Base64URL differ?
It uses - and _ instead of + and /, and often omits padding.
Can every decoded value be shown as text?
No. The result is bytes and may be an image, archive, certificate, or another binary format.
Is Base64 encryption?
No. It is reversible encoding and provides no confidentiality.