Base64 String Validator

Paste a string to check whether it is valid Base64.

How it is calculated

The tool checks a string against standard Base64 in three steps. First, spaces at the very start and end are trimmed. Second, the length must be a multiple of 4 and the string must match [A-Za-z0-9+/]*={0,2}, meaning only the 64 alphabet characters followed by at most two = signs at the end. Third, it must decode strictly. The result is Valid: Yes or No, the length of the trimmed string, and the number of decoded bytes (0 when the string is invalid). Decoded size follows bytes = length ÷ 4 × 3 − padding, where padding is the number of = signs. A string that is empty returns nothing. Spaces or line breaks inside the string, the URL-safe characters - and _, and missing padding all make it invalid. The tool does not show the decoded text and does not check whether the final unused bits are zero.

Worked example

Check SGVsbG8gV29ybGQ=. Step 1: count the characters, which gives an input length of 16, a multiple of 4. Step 2: every character belongs to the standard alphabet and the single = is at the end. Step 3: the string decodes cleanly, so the tool shows Valid: Yes. Step 4: the decoded size is 16 ÷ 4 × 3 − 1 = 11 bytes. (Decoded, the text is Hello World.)

Try this example →

Common mistakes

  • Pasting URL-safe Base64, which uses - and _ as in many JWT parts. The tool checks the standard alphabet only, so SGVsbG8_V29-bGQ= is reported as invalid; replace - with + and _ with / first.
  • Dropping the trailing = padding. SGVsbG8gV29ybGQ (15 characters) is invalid, because the length is not a multiple of 4. Many libraries accept this, but the standard form requires the padding.
  • Pasting line-wrapped Base64 as found in emails or certificates. Line breaks and spaces inside the text make the check fail, so join the lines into one first.
  • Adding one = too many. SGVsbG8gV29ybGQ== has 17 characters and is invalid; at most two padding signs are allowed.
  • Taking Valid: Yes as proof that the data is meaningful. It only says the string is well-formed Base64; the bytes could still be random or not the file you expect.

Sources

About this calculator

Base64 encoding turns every 3 bytes of binary data into 4 ASCII characters drawn from a 64-character alphabet (A–Z, a–z, 0–9, +, and / in the standard variant), padding the final group with = characters when the input length isn't a multiple of 3. A well-formed Base64 string must therefore have a length that's a multiple of 4, use only characters from that alphabet, and follow the correct padding rules — this calculator checks all three and reports the decoded byte length.

Developers use it to debug malformed API payloads, JWT tokens, or data URIs, and when handling MIME-encoded email attachments or binary data embedded in JSON or XML, where a single corrupted character or missing padding character can silently break decoding downstream.

Was this helpful?

You can pick up to 3 reactions.

Comments (1)

  • Editorial team

    This check is for the standard alphabet with padding. A URL-safe string that uses - and _ in place of + and /, or a string that leaves out the trailing = signs, will be reported as not valid even though many libraries accept it. Line breaks inside the text are not accepted either, only spaces at the ends are trimmed. Which variant are you validating? Tell us if you need URL-safe support.

Popular calculators

All Calculators