About

Base64 encoding represents binary data in 64 ASCII characters. The specification (RFC 4648) requires output length to be a multiple of 4. When the encoded byte stream does not align, = padding characters are appended. Many systems strip this padding for URL safety or compactness. Feeding unpadded Base64 into a strict decoder (most standard library implementations) causes immediate failure. This tool calculates the missing pad count as p = (4 − len mod 4) mod 4 and appends exactly that many = characters. It processes single strings or batches of hundreds of lines.

Note: this tool assumes input uses standard Base64 or Base64URL alphabets. It does not re-encode data. If your input contains characters outside A - Z, a - z, 0 - 9, +/-_, the output may decode to garbage regardless of correct padding. Pro tip: some JWT libraries silently strip padding from the payload segment. Re-padding before manual inspection avoids cryptic parse errors.

Formulas

The padding algorithm is deterministic. Given a Base64 string with all existing = characters stripped, compute the number of padding characters required:

p = (4 − (L mod 4)) mod 4

Where L = length of the input string after removing any trailing = characters, and p = number of = characters to append. The result is always p ∈ {0, 1, 2}. A value of 3 indicates corrupt input because Base64 encodes 3 bytes into 4 characters. A single Base64 character carries 6 bits. Therefore one leftover character after stripping means only 6 bits remain, which cannot represent a complete byte.

output = stripped + "="⋅repeat(p)

The valid Base64 alphabet check uses the pattern: chars ∈ [A - Z, a - z, 0 - 9, +, /] for standard Base64 and [A - Z, a - z, 0 - 9, -, _] for Base64URL. Whitespace and line breaks are ignored during validation but preserved in batch mode line splitting.

Reference Data

Original Length mod 4	Padding Needed	Pad Characters	Example (Unpadded)	Example (Padded)	Decoded Text
0	0	None	`SGVsbG8=`	`SGVsbG8=`	Hello (already has pad)
1	3	===	Invalid state	N/A	Cannot occur in valid Base64
2	2	==	`YQ`	`YQ==`	a
3	1	=	`YWI`	`YWI=`	ab
Common Real-World Scenarios
0	0	None	`dGVzdA==`	`dGVzdA==`	test
2	2	==	`dGVzdA`	`dGVzdA==`	test
3	1	=	`Zm9v`	`Zm9v`	foo (already aligned)
3	1	=	`Zm9vYg`	`Zm9vYg==`	foob
0	0	None	`Zm9vYmE=`	`Zm9vYmE=`	fooba
2	2	==	`Zm9vYmFy`	`Zm9vYmFy`	foobar (aligned, no pad needed)
Base64URL Variants (RFC 4648 §5)
2	2	==	`eyJhbGciOiJIUzI1NiJ9`	`eyJhbGciOiJIUzI1NiJ9`	JWT header (already aligned)
2	2	==	`SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`	`SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c=`	JWT signature (URL-safe chars)
3	1	=	`PDw-Pz4`	`PDw-Pz4=`	<<?> (URL-safe)
Encoding Standards Reference
RFC 4648		The Base16, Base32, and Base64 Data Encodings (mandatory padding)
RFC 7515 (JWS)		JSON Web Signature - uses Base64URL without padding
RFC 7516 (JWE)		JSON Web Encryption - uses Base64URL without padding
MIME (RFC 2045)		Base64 Content-Transfer-Encoding with line breaks every 76 chars
PEM (RFC 7468)		Base64 with header/footer lines, 64-char line wrapping

Frequently Asked Questions

A remainder of 1 after dividing by 4 means only 6 bits of data exist in that trailing character. Since Base64 encodes full bytes (8 bits), a single trailing character cannot represent any complete byte. This is structurally invalid input. The tool flags these lines as corrupt rather than blindly appending 3 padding characters, which would produce garbage on decode.

No. The tool only adds missing = padding characters. It does not replace + with - or / with _. Both alphabets accept = as the padding character. If you need alphabet conversion, that is a separate transformation step.

RFC 7515 (JSON Web Signature) explicitly mandates Base64URL encoding without padding. The = character is reserved in URI query parameters and would require percent-encoding (%3D), increasing token size. Since the decoder can deterministically reconstruct padding from string length, omitting it reduces transmission overhead without information loss.

Yes. Paste the entire block (without PEM headers like -----BEGIN CERTIFICATE-----). The tool operates in batch mode, processing each line independently. PEM and MIME use line wrapping at 64 or 76 characters respectively. Each wrapped line except the last is inherently a multiple of 4 in length, so only the final line typically needs padding restoration.

No. Padding characters carry zero informational content. They exist solely to signal the decoder how many trailing zero-bits to discard. The decoded byte sequence from YQ== is identical to that from YQ in tolerant decoders. The difference is that strict decoders (Java's Base64.getDecoder(), Python's base64.b64decode() without validate=False) reject the unpadded form.

Whitespace characters (spaces, tabs, carriage returns) within a line are stripped before computing the padding. This matches the behavior of MIME decoders (RFC 2045) which ignore linear whitespace. The output contains the cleaned string with correct padding appended.