Enter exactly Hello>? in Encode mode. Its UTF-8 bytes are 48 65 6C 6C 6F 3E 3F. Seven bytes leave one byte in the final group, so padded form needs two equals signs. The last data sextets also reach values that differ between the standard and URL-safe alphabets, making this small fixture useful for checking both settings.

Standard padded result

Choose Standard Base64 and Padded. The exact output is SGVsbG8+Pw==. Plus is data symbol 62, and the two equals signs mark that only one source byte occupied the final group. A decoder configured for standard padded Base64 must accept this spelling and return the original seven bytes before UTF-8 decoding.

Base64URL unpadded result

Choose Base64URL and Unpadded. The exact output is SGVsbG8-Pw. Dash replaces plus and the two equals signs are omitted. The source bytes do not change. Base64Lens does not claim this setting is correct for every URL field; the surrounding protocol must specify both the alphabet and whether padding is allowed.

Mismatched settings fail visibly

Try decoding SGVsbG8+Pw== as unpadded base64url. Plus belongs to the standard alphabet and equals signs are forbidden, so the input must not be repaired into a success. Then decode SGVsbG8-Pw with standard padded settings: dash belongs to the other alphabet and the padded length is incomplete. These failures reveal a contract mismatch before copied output reaches another system.