Skip to content
yutils
Example

Input (encode mode)

Hello yutils 👋

Output

SGVsbG8geXV0aWxzIPCfkYs=

Note

UTF-8 based — multi-byte characters (Korean, emoji) round-trip safely. Output is ASCII, safe to embed in email, HTTP headers, JSON, etc.

Usage / FAQ

When to use

  • Decode Base64 strings embedded in API responses into readable text
  • Encode non-ASCII text safely into email or HTTP headers
  • Generate Basic Auth `username:password` headers
  • Handle multi-byte characters (Korean, emoji) safely via UTF-8
  • Inspect the payload inside `data:` URI scheme images

FAQ

Q.How is this different from native btoa/atob?
A.JavaScript's btoa/atob only handle latin-1 — multi-byte (Korean, emoji) breaks. yutils uses TextEncoder/TextDecoder for safe UTF-8 round-trip.
Q.Can I use this directly in URLs?
A.Standard Base64 contains `+` `/` `=` which conflict with URL syntax. For URL safety use Base64URL (what JWT uses) or pair this with the URL Encode tool.
Q.Is Base64 encryption?
A.No — it's plain encoding, trivially reversible. For password/secret protection use SHA-256, bcrypt, or HMAC.
Fun facts

  • The `64` in Base64 is the size of the output alphabet. 6-bit integers (2⁶=64) align cleanly with bit shifts, making it the sweet spot. Had it been Base65, 6 bits would no longer suffice and every decoder on Earth would be significantly more complex.

    RFC 4648

  • Base64 encoding inflates data by about 33%. Three bytes (24 bits) become four characters (6 bits each). A 1 MB image inlined as Base64 weighs ~1.33 MB — which is why `data:` URI images get heavy fast.

    Wikipedia — Base64

  • Base64 first appeared in 1987's PEM (Privacy-Enhanced Mail, RFC 989). In the SMTP era, getting non-ASCII bytes (images, Korean text, …) through a 7-bit ASCII channel safely was the original mission — and that's still the job today.

    RFC 989 (1987)

Related tools

See all in this category →