Validate a Base64 string
Check that a string is well-formed standard Base64 — groups of four characters from the A-Z/a-z/0-9/+/ alphabet, with correct = padding at the end.
Last updated
^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$Matches
- SGVsbG8sIFdvcmxkIQ==
- YQ==
Doesn’t match
- not base64 at all!!
- SGVsbG8_IFdvcmxk
Why it’s written this way
(?:[A-Za-z0-9+/]{4})* consumes as many complete four-character groups as the string has — Base64 always encodes in units of four output characters per three input bytes. The final optional group then handles the two padding shapes a string can legally end with: two data characters plus '==', or three data characters plus a single '='.
Anchoring with ^ and $ matters here more than in most patterns in this library — without them, a string with garbage at the start or end would still report a match on the valid portion inside it, which defeats the point of validating the whole string.
Edge cases to know
- →An empty string technically satisfies this pattern, since the repeated group can match zero times and the padding group is optional — decide separately whether empty input should count as valid for your use case.
- →This is the standard alphabet only. Base64url, used in JWTs and URLs, swaps + and / for - and _ and usually drops padding, so it needs a different pattern.
- →Matching the shape does not mean the content decodes to anything meaningful — it only proves the string is legal Base64 syntax.
Part by part
- ^
- Anchored at the start, because this is a validator rather than a finder — base64 is checked as a whole value, never located inside prose.
- (?:[A-Za-z0-9+/]{4})*
- Zero or more complete four-character groups. Base64 encodes three bytes into four characters, so a valid string is built from these blocks.
- [A-Za-z0-9+/]{2}==
- The final block when one byte remains: two characters and two padding signs.
- [A-Za-z0-9+/]{3}=
- The final block when two bytes remain: three characters and one padding sign. Exactly one of the two tail forms can apply.
- $
- Anchored at the end, so trailing whitespace or a stray character fails the whole string rather than being ignored.
Common mistakes
^[A-Za-z0-9+/=]+$Putting the equals sign in the class allows padding anywhere, so "=a=b=" validates. Padding is only ever one or two characters at the very end, and that position is the point.
^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$^(?:[A-Za-z0-9_-]{4})*(?:[A-Za-z0-9_-]{2}==|[A-Za-z0-9_-]{3}=)?$This is the URL-safe alphabet, which swaps plus and slash for hyphen and underscore. It is a legitimate variant but a different one — validating URL-safe input against the standard pattern, or the reverse, rejects valid data.
^(?:[A-Za-z0-9+/]{4})+$Requiring at least one full group and no padding rejects every string whose input length was not a multiple of three, which is two thirds of all inputs.
Questions
Does a match mean the decoded content is meaningful?
No. Base64 is an encoding, not a format — any four valid characters decode to three bytes of something. Whether those bytes are an image, a JSON document or noise is a separate question the pattern cannot reach.
Why is padding optional here?
Because plenty of real encoders omit it, particularly in URLs and JWT segments where the trailing equals signs are awkward. Accepting both forms is more useful than being strict about a character that carries no information.
Does it handle multi-line base64?
No. MIME wraps base64 at 76 characters with line breaks, and the anchors reject any newline. Strip whitespace before validating if your input comes from an email or a PEM file.
Is base64 a form of encryption?
No, and treating it as one is a genuine security mistake. It is reversible by anyone with no key at all — its purpose is transporting binary safely through text channels, not concealing anything.