Base64
Decoder

Data URIs embed images, fonts, and small files directly inside HTML or CSS as data:image/png;base64,iVBORw0KGgo…. Useful for icons under 4 KB that would otherwise cost an HTTP round-trip. Above 4 KB the encoding penalty (Base64 is 33 % larger than raw bytes) outweighs the round-trip savings, so use sprite sheets or HTTP/2 multiplexing instead.

HTTP Basic Auth sends credentials as Authorization: Basic <base64(user:password)>. This is encoding, not encryption — anyone with the header can decode the credentials in one step. Only safe over TLS. The decoder is the fastest way to inspect a curl -v dump and verify which user is being authenticated.

JWT tokens are three Base64URL segments separated by dots: header.payload.signature. Base64URL replaces + with - and / with _ and drops padding. To read a JWT here, paste one segment at a time after swapping - back to + and _ back to /, and add = padding until the length is a multiple of 4.

Email attachments over SMTP use Base64 (specifically MIME Base64 with line breaks every 76 chars) because SMTP was designed for 7-bit ASCII text. Cryptographic keys and certificates in PEM format (-----BEGIN PRIVATE KEY-----) are Base64 wrapped around DER binary. SVG inlining, CSP nonces, OAuth state tokens, WebAuthn credential IDs — Base64 is everywhere in modern web infrastructure.

Encoding takes raw bytes (text, binary, image) and produces a Base64 ASCII string. The output is always 33 % larger than the input (3 input bytes → 4 output chars), padded with = to make the length a multiple of 4. Encoding is deterministic and lossless: encode then decode and you get the exact original bytes back.

Decoding reverses the process. Take 4 Base64 chars → produce 3 bytes. The input must be valid Base64 — characters outside A-Za-z0-9+/= make the decode fail, while spaces and line breaks are ignored.

Text encoding inside Base64 is a separate concern. Base64 encodes bytes, not characters. If you Base64-encode the string café, the result depends on whether you encoded UTF-8 bytes (Y2Fmw6k=) or Latin-1 bytes (Y2Fm6Q==). ConverterUp decodes as UTF-8 and, if the bytes are not valid UTF-8, shows them character by character as a fallback.

The padding question: standard Base64 always pads to a multiple of 4 with =. Base64URL (used by JWT, OAuth, WebAuthn) often strips the padding because URLs hate =. A string of length 22 needs 2 padding chars to reach 24 — add them before decoding if the tool reports invalid input.

URL-safe Base64 (Base64URL, RFC 4648 §5) replaces two characters: + → -, / → _. The padding char = is also typically dropped. ConverterUp expects standard Base64, so convert - back to + and _ back to / before pasting URL-safe strings.

Padding errors are the #1 source of 'invalid Base64' bugs. A token of length 11 cannot decode — Base64 strings must be a multiple of 4. The fix is to append 1, 2, or 3 = until the length is a multiple of 4. Some tools silently accept unpadded input; some throw an error. If you see 'incorrect padding', add equals signs until the length divides by 4.

Line breaks in MIME Base64 (RFC 2045) come every 76 chars because old SMTP servers had line-length limits. Modern decoders strip line breaks before decoding, but some strict implementations do not. If you see decode errors on a Base64 blob from an email or PEM file, run a regex replace /\s/g first to collapse all whitespace, then decode.

Encoding does not encrypt. This is worth repeating because Base64 looks like ciphertext and even experienced developers occasionally treat it as obfuscation. Anyone with the Base64 string can recover the original bytes instantly. Never use Base64 to 'hide' API keys, passwords, or PII — it adds zero security. Use real encryption (AES-GCM, age, libsodium) for actual secrets, and treat Base64 purely as a binary-to-ASCII transport format.