Base64 Encoder & Decoder
Convert UTF-8 text to and from Base64 and RFC 4648 URL-safe Base64url locally in your browser.
Local Workspace (base64-codec)
How to Use Base64 Encoder & Decoder
- 1Select Encode to Base64 or Decode from Base64 at the top of the workspace.
- 2Check RFC 4648 base64url (- and _) and Omit Padding (=) when generating URL-safe tokens or JWT segments.
- 3Paste your text or Base64 string to view the conversion immediately, then copy or download the .txt output.
Technical Specifications & Guardrails
- Full UTF-8 TextEncoder/Uint8Array/TextDecoder pipeline handles multi-byte Unicode without btoa crashes
- RFC 4648 Section 5 URL-Safe base64url mode (- and _) with optional '=' padding removal
- Fatal UTF-8 decoder check rejects corrupted binary sequences instead of silently emitting replacement characters
- Swap Direction & Input button lets you roundtrip test payloads in one click
Practical Example: Inspecting and Encoding Multi-Language API Headers & JWT Payloads
- Sample Input
- A JSON payload containing Sinhala, Japanese, and emoji characters that throws InvalidCharacterError in standard window.btoa().
- Verified Local Output
- Cleanly serialized into UTF-8 byte-accurate Base64 or unpadded RFC 4648 base64url and verified back to identical UTF-8 text.
Operational Limits & Browser Guardrails
Supports UTF-8 text payloads up to 5 MB locally in browser memory. Decoding validates RFC 4648 alphabet rules and enforces fatal UTF-8 byte sequence verification; raw non-text binary files (such as compiled executables) will display a non-UTF-8 warning upon decode.
Frequently Asked Questions
Why does standard JavaScript btoa() fail on Unicode text, and how does FetchToolKit fix it?
Native btoa() only accepts Latin-1 code points (0x00 to 0xFF) and throws InvalidCharacterError on multi-byte characters. FetchToolKit encodes strings into a UTF-8 Uint8Array via TextEncoder before Base64 serialization so every Unicode script converts cleanly.
What is the difference between standard Base64 and RFC 4648 base64url?
Standard Base64 uses '+' and '/', which have special meaning in URLs and file paths. RFC 4648 Section 5 base64url replaces '+' with '-', replaces '/' with '_', and allows omitting trailing '=' padding.
Does decoding require '=' padding characters to be present?
No. The decoder automatically restores missing '=' padding (modulo 4) and normalizes both standard Base64 and base64url alphabets before decoding.