Convert Base64 in the browser
Convert UTF-8 strings and files to Standard Base64, Base64URL, or Data URL, and restore Base64 to text or files. Input is not sent to conversion APIs.
Base64 Open Encoder / DecoderConclusion: Use UTF-8 for the character encoding before encoding and after decoding
Convert a Japanese String to a UTF-8 byte sequence with TextEncoder, then encode that byte sequence as Base64. When decoding, restore the byte sequence from Base64 and restore the String with TextDecoder using UTF-8.
Base64 text itself is ASCII, but text can become garbled if the original byte sequence is misinterpreted as Shift_JIS or Latin-1.
Keep the original data, then check the format, character encoding, Padding, and conversion result in order.
Check the boundary between strings and byte sequences.
JavaScript strings hold Unicode characters, but btoa assumes a binary string where every code unit fits in one byte. Japanese and many emoji do not meet that assumption and result in InvalidCharacterError.
This tool treats text as UTF-8. It has no character encoding selection feature to directly restore existing Base64 in Shift_JIS, EUC-JP, or similar to text, so save it as binary and decode it in a supported environment.
| Account to check | What to check | Supported |
|---|---|---|
| Original String | Japanese, Emoji, and accents | TextEncoder UTF-8 |
| Encode | Enter a byte sequence | Convert to Base64 |
| Decode | Byte sequence from Base64 | TextDecoder UTF-8 |
| Existing Data | Original Encoding unknown | Inspect as binary |
Steps to check with Base64 Encoder / Decoder
- Select Encode and Standard Base64.
- Enter text such as Hello 😀.
- Copy the converted Base64 and switch to Decode.
- Verify an exact match with the original Japanese and emoji.
This tool uses TextEncoder and TextDecoder, so it can round-trip Japanese and emoji in UTF-8.
How to isolate issues when conversion fails
Do not try to fix mojibake text by re-encoding it; identify the original byte sequence and the incorrectly used character encoding.
If a UTF-8 byte sequence is converted to a String as Latin-1 and then saved again, even the original byte sequence may change. Preserve the original Base64 and validate it with different Encodings.
- Check whether a Unicode string is passed directly to btoa
- Was the byte sequence after decoding read as UTF-8?
- Whether the original data uses Shift_JIS or similar
- Check whether URL Decode or JSON Escape was applied along the way.
Supported scope of the current Base64 Encoder / Decoder
DevelopTools processes input in the browser. It supports encoding UTF-8 strings to standard Base64 and unpadded Base64URL; decoding both forms and Base64 data URLs; removing spaces and line breaks; padding completion; converting files to Base64 and data URLs; restoring files from Base64; previewing supported images; copying; downloading; and displaying byte counts and growth rates. It does not save input, conversion results, or file names to history or LocalStorage, or send them to conversion APIs.
| Category | Current tool operation |
|---|---|
| Strings | Convert to a UTF-8 byte sequence with TextEncoder, then Encode as Standard Base64 or unpadded Base64URL |
| Decode | Remove whitespace and line breaks, identify URL-safe characters, and add missing padding. Validate invalid characters, length, and padding. |
| Data URL | Separate the base64 prefix and payload, then restore the MIME type. Percent-encoded data URLs are unsupported. |
| File | Encode the file selected by the user as a byte sequence. After decoding, save it with the specified MIME type and file name. |
| Display | Do not forcibly convert non-UTF-8 Binary to text; guide users to save it as a File. PNG, JPEG, GIF, WebP, and SVG can be previewed |
Do not confuse Base64 with encryption, hashing, or signature verification.
Base64 is not encryption. It is a reversible encoding that represents byte sequences with ASCII characters, and anyone with a decoder can recover the original data. It is therefore not a way to keep passwords, API tokens, cookies, or personal information secret. Confidentiality requires appropriate encryption and key management, password storage requires a dedicated password hash, and tamper detection requires a mechanism suited to the purpose, such as a signature or MAC.
Even if you can read a JWT's header and payload by Base64URL decoding them, you cannot conclude that the signature, expiration, issuer, and audience are correct. Basic authentication credentials are also only a Base64 representation, so use HTTPS for actual communications and use only dummy values such as USERNAME, PASSWORD, and SAMPLE_TOKEN in articles, tests, and screenshots.
Even when you need to transform real credentials or customer data, check shared devices, clipboard history, screen sharing, and storage locations.
Check the specification and Web API using primary sources
Use RFC 4648 for the alphabet, padding, and Base64URL; RFC 7617 for HTTP Basic authentication; and JOSE-related RFCs for JWT Base64URL. Check MDN and the compatibility table for the browser you use for support of JavaScript btoa/atob, TextEncoder/TextDecoder, and Uint8Array.
Example: Round-trip こんにちは😀 in UTF-8
For text containing Japanese and Supplementary Plane emoji, check UTF-8 byte count as well as character count.
Decoding the encoded result returns the original こんにちは😀, including code points.
- Record the original text in a separate field
- Base64 Encode as UTF-8
- Base64-decode the result
- Compare with the original text character by character
Visually similar Unicode characters and normalization differences may also exist, so compare by code point if necessary.
Frequently asked questions
- Is Base64 encryption?
- No. It is an Encoding that represents a Byte sequence as a string and can be restored to the original data. Simply converting a Password or Token to Base64 does not protect it.
- Are entered strings and files sent to a server?
- Base64 conversion runs in your browser. There is no process that saves input, results, or filenames to a conversion API, history, or LocalStorage.