Base64 Encoder/Decoder
Why does Base64 reject a value with the right equals signs?
Equals signs are only part of Base64 validation. ForgeHub also decodes the bytes and encodes them again; the result must match your input after allowed whitespace is removed. For example, Zg== decodes to f, while Zh== fails the padding-bit check. Regenerate the encoding from known original text rather than guessing replacement characters.
Read which check actually failed
If Decode to text reports Invalid Base64 padding bits, the value has already passed the app's alphabet and padding-shape check. Adding another equals sign addresses the wrong check. The decoder is rejecting how the final data characters represent the bytes, even though the overall arrangement looks acceptable.
Start with a small comparison: paste Zg== into Input and select Decode to text. The result is f. Replace Input with Zh== and decode again. This time the padding-bit error appears. Both strings have two data characters followed by two equals signs, but only the first passes the app's canonical-form check.
Understand the decode-and-encode comparison
The implementation removes its allowed whitespace, calls atob to obtain bytes, then calls btoa on those bytes. It compares that fresh encoding with the cleaned input. Here, canonical means the exact standard Base64 spelling produced by that re-encoding step. A mismatch stops conversion before the UTF-8 text decoder runs.
For Zh==, the browser byte decoder yields the same byte as Zg==, but re-encoding that byte produces Zg==. The mismatch explains why the app rejects the alternate spelling. A second example is Zm8=, which decodes to fo: Zm9= has the same padding shape but fails the same comparison. The unused bits in the final data character matter to this check; equals signs alone cannot establish canonical form.
Regenerate from a known original
If you have the original text, use that as the repair source. Enter exactly f, with no added space or line break, and select Encode to Base64. Output becomes Zg==. Select Use output as input, then Decode to text to confirm that the returned text is the intended f. For the two-letter original fo, the encoded output is Zm8=.
If you only have a rejected value, return to its producer and request a fresh standard Base64 encoding or the original text. Do not change the last letter until the error disappears and assume you recovered the intended message. Acceptance confirms that a value passes this converter's checks; it does not establish that you copied the right content. The app has no automatic repair action.
Separate neighboring errors before retrying
Zg without its two equals signs fails the earlier standard-Base64 check. Spaces, tabs, carriage returns, line feeds and form feeds are removed before that check, so surrounding ordinary spaces or a line break do not explain a padding-bit mismatch. That cleanup does not remove quotation marks or convert Base64URL characters.
A value can pass the canonical check and still fail later. For example, /w== reaches the UTF-8 check, which rejects its decoded bytes as invalid UTF-8 text. Rewriting padding is not a solution to that error. This app converts text; it cannot export arbitrary decoded binary as a file. Use the actual error message to decide whether to revisit the encoding or the kind of content you are trying to decode.
Check success before using the visible result
After the successful Zg== example, trying Zh== leaves f visible in Output. That is the retained successful result, not a newly accepted decoding. The failure status explicitly says the previous successful output is unchanged. Correct Input, run Decode to text again and look for Decoded successfully before copying or downloading a result.
Keep the original text available while investigating. Use output as input copies whatever Output currently contains, including an older result after a failure. It does not recover the rejected input or correct padding bits. Working through one short known example first makes that distinction easier to see.
AI-assisted ForgeHub editorial. App capabilities were checked against its implementation; this guide is not an independent review.
Frequently asked questions
Does every standard Base64 value need equals signs?
No. The app accepts complete groups of four Base64 characters without equals signs. For example, encoding foo produces Zm9v. Padding is required when the final group needs it, as in Zg== for f or Zm8= for fo.
Will removing line breaks fix a padding-bit error?
The decoder already removes ASCII spaces, tabs, carriage returns, line feeds and form feeds before checking canonical form. Removing those characters yourself does not change the comparison that caused this particular error.
Can I use Encode to Base64 directly on the rejected value to fix it?
That encodes the literal characters of the rejected value as new text. It does not repair their intended decoding. Encode the known original text instead, or obtain a fresh value from its producer.