/^/
MediumSecurity5 min read

Base64 String Regex

Matches a standard Base64-encoded string, enforcing the correct alphabet, length multiple of four, and valid padding.

#base64#encoding#security#validation#text-processing

Regex Pattern

^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$

Pattern Breakdown

Hover over a token to see what it does.

^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$
TokenMeaning
^Anchors the match to the start of the string
(?:[A-Za-z0-9+/]{4})*Zero or more complete groups of 4 Base64 alphabet characters
[A-Za-z0-9+/]{2}==Alternative: a final 2-character group followed by two padding equals signs
[A-Za-z0-9+/]{3}=Alternative: a final 3-character group followed by one padding equals sign
==|The alternation bar separating the two padding forms; the whole trailing group is optional, allowing strings whose length is already an exact multiple of 4
$Anchors the match to the end of the string

Detailed Explanation

What it does

This pattern validates that a string conforms to the standard Base64 encoding alphabet (A-Z, a-z, 0-9, +, /) and follows the required padding rules: the encoded length must be a multiple of 4, with 0, 1, or 2 trailing = padding characters depending on how many bytes of input remain in the final group.

Why it works

Base64 always encodes input in 4-character output groups, so the pattern first consumes any number of complete 4-character groups with (?:[A-Za-z0-9+/]{4})*. The optional trailing alternation then handles the two valid padded endings: a 3-character group plus one = sign (2 encoded bytes) or a 2-character group plus two = signs (1 encoded byte), correctly modeling how Base64 pads incomplete final groups.

Common use cases

  • Validating that a string received from an API or config file is properly formatted Base64 before decoding it
  • Checking file upload payloads that are expected to arrive as Base64-encoded data URIs
  • Sanity-checking JWT segments or encoded credentials before attempting to decode them
  • Filtering log or database fields to detect accidentally double-encoded or corrupted Base64 values

Edge cases

  • Strings without any padding, whose length is already a multiple of 4 like 'YWJjZA==', are matched by the repeated group alone when no padding is needed
  • A single padding character (one =) is only valid at the very end preceded by exactly 3 alphabet characters in the final group
  • Two padding characters (==) are only valid at the very end preceded by exactly 2 alphabet characters in the final group
  • Whitespace or line breaks sometimes present in Base64 blocks (e.g. MIME-encoded email attachments) are not tolerated by this strict pattern
  • An empty string technically satisfies the pattern since all groups are optional, which may be surprising for callers expecting non-empty input

Limitations

  • Does not validate Base64 URL-safe variants that use - and _ instead of + and /
  • Does not guarantee the decoded bytes represent any particular expected format (e.g. valid UTF-8 or a specific file type)
  • Rejects Base64 blocks that include embedded newlines for line wrapping, which some legacy encoders produce
  • Accepts the empty string as valid, which callers may need to explicitly exclude with an additional length check

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

SGVsbG8sIFdvcmxkIQ== YQ== YWJj

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const base64Regex = /^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/;
console.log(base64Regex.test('SGVsbG8=')); // true

Common Mistakes

Using a simple [A-Za-z0-9+/=]+ character class without checking length or padding position, which accepts malformed strings like 'A===' or odd-length input

Fix: Structure the pattern around fixed-size groups so padding can only appear correctly at the very end

Not accounting for the URL-safe Base64 variant that uses - and _ instead of + and /

Fix: Swap the character class to [A-Za-z0-9\-_] (and adjust padding rules) when validating Base64URL rather than standard Base64

Assuming a successful regex match guarantees the content decodes to something meaningful

Fix: Treat regex validation as a structural check only; still handle decode errors or unexpected content after decoding

Performance Notes

  • The repeated 4-character group (?:[A-Za-z0-9+/]{4})* processes input in fixed chunks, which is efficient and avoids ambiguous backtracking
  • The trailing alternation between the two padding cases is only evaluated once, at the end of the string
  • For very large Base64 blobs (e.g. embedded file data), consider validating length as a multiple of 4 with simple arithmetic before running the full regex as a cheaper pre-check

Browser Compatibility

EngineSupportedNotes
ChromeYes
FirefoxYes
SafariYes
EdgeYes
Node.jsYes