Base64 Encoder and Decoder
Encode text to Base64, decode Base64 back to UTF-8, and check padding, Base64URL alphabet differences, data URI prefixes, and binary-output boundaries before copying.
- Encode short UTF-8 text snippets into standard Base64.
- Decode standard Base64 or Base64URL-style input and inspect readable output.
- Check padding, whitespace, data URI prefixes, and secret-handling risks before copying.
Static fallback example
The live Base64 workbench runs in the browser. If it does not load, use this static example to confirm the UTF-8 text to Base64 pattern, then enable JavaScript or reload the page to encode, decode, and validate real input.
This fallback is a read-only example. It cannot detect invalid padding, Base64URL variants, binary bytes, or data URI prefixes; use the browser workbench for those checks.
About this tool
The Base64 Encoder and Decoder converts UTF-8 text into Base64 and decodes Base64 or Base64URL-style strings back into readable text when the decoded bytes are valid UTF-8.
When this tool is useful
Use it for small API examples, JWT payload inspection, copied configuration values, data URI fragments, documentation samples, and quick checks where the input is safe to handle locally.
Base64 is a reversible encoding format. It is not encryption, compression, authentication, or proof that a token-looking value is safe to share.
Input and output example
Input text: Hello, 世界
Base64 output: SGVsbG8sIOS4lueVjA==
Common decode errors
Decode failures commonly come from missing padding, Base64URL substitutions, pasted data: prefixes, copied quotes, inserted line breaks, or bytes that are binary rather than valid UTF-8 text.
Privacy boundary
Treat unknown Base64 as potentially sensitive. It may decode to API keys, cookies, basic-auth headers, private documents, or user data.
Before copying the result
Review the output against the original value, the expected alphabet, and the place where the result will be pasted. A successful decode only proves the string can be decoded; it does not prove the value is trusted, current, or safe to expose.
For Base64, keep the original text or encoded string visible until you confirm padding, Base64URL substitutions, line breaks, UTF-8 decoding, data URI prefixes, and whether the decoded value represents readable text or binary data.
FAQ
Is Base64 secure?
No. Base64 is reversible encoding, not encryption. Anyone with the string can decode it.
Can it handle Chinese characters and emoji?
Yes. The browser workbench uses a UTF-8 path for text, so Chinese characters and emoji can be encoded and decoded when the input represents valid UTF-8 text.
What is the difference between Base64 and Base64URL?
Standard Base64 uses + and /, while Base64URL uses - and _. Some URL-safe values also omit padding, so confirm the expected variant before copying.
Base64 decode checklist for padding, Unicode, and Base64URL
Base64 is an encoding layer used when binary or structured text must travel through systems that expect plain ASCII. It is common in data URLs, email MIME parts, certificates, small assets, and API examples, but it is not encryption.
Recommended workflow
- Identify the source type before decoding: plain text, UTF-8 text, image data, a JWT segment, or a longer binary blob.
- Decode a short sample first. If the output contains replacement characters, the original may not be UTF-8 text.
- When encoding for a URL or query string, verify whether the receiving system expects standard Base64 or URL-safe Base64.
- After copying the result, check padding characters, line wrapping, and whether spaces were inserted by email, chat, or rich text editors.
Example review
Input: Hello Ymir Tool
What to verify: SGVsbG8gWW1pciBUb29s — the result represents text bytes, not a secret or a hash.
Common mistakes to check
- Treating Base64 as a security feature. Anyone can decode it.
- Removing padding when the target decoder expects = characters.
- Mixing standard Base64 with URL-safe Base64 where + and / become - and _.
- Trying to display binary output as text without knowing the original file type.
Copying and verification standard for Base64
Before copying output from this page, confirm the exact variant, padding policy, and decoded content type. For text, verify UTF-8 characters such as Chinese, emoji, quotes, and line breaks. For tokens or data URIs, keep the wrapper context so the copied value remains auditable.
For repeatable work, save a short non-sensitive sample and the expected encoded form. That gives you a regression example when a browser extension, rich-text copy, cached script, or upstream data source changes the behavior you observe.
Operational questions for Base64 decoding
Why does decoded text look broken?
The input may represent binary data, a different character set, or a compressed payload rather than plain UTF-8 text.
When should I use img2base64 instead?
Use a dedicated image-to-Base64 flow when the source is a file and you need a data URL or CSS-ready asset string.
Review standards by context
The same tool can support several workflows, but each workflow needs a different acceptance check. Use the following context notes to decide whether the output is ready to copy or whether the source material needs another pass.
- Text transfer: Verify the decoded text uses the expected character set and does not include copied rich-text characters.
- Data URL: Separate the MIME prefix from the encoded payload before decoding or reusing the result.
- API token-looking value: Do not assume a Base64-looking value is safe to share; decode only non-sensitive samples or use an approved internal workflow.
When a value will be used in production documentation, an incident report, a customer reply, or a configuration change, keep the source value and the transformed value together. That record makes the tool result auditable instead of leaving only a copied output with no explanation.
A complete Base64 review also checks what encoding cannot do. Base64 can make bytes easier to transport, but it does not encrypt, authenticate, compress, validate permissions, verify JWT signatures, or make a token safe to expose.
Base64 review workflow for text, tokens, data URIs, and API payloads
Base64 is a transport encoding. It helps binary or structured data survive systems that expect text, but it does not encrypt, authenticate, or sanitize the original content. A useful Base64 page should therefore help users decode carefully, recognize padding and alphabet differences, and decide whether the decoded value should be exposed at all.
Use this page for controlled inspection of short samples: an API field, a data URI fragment, a JWT segment, or a small UTF-8 text value. For large files, secrets, production credentials, or user records, work inside your approved local tooling and security process instead of pasting raw material into a browser workflow.
Use the tool as a review workflow
- Identify the variant first: standard Base64, URL-safe Base64, MIME-wrapped Base64 with line breaks, or a data URI that includes a media-type prefix.
- Decode only the smallest useful segment. For JWTs, inspect the header or payload segment without treating the token as safe or verified.
- Check padding and alphabet characters. Standard Base64 commonly uses + and /, while URL-safe Base64 uses - and _.
- After decoding, determine the content type. The result may be UTF-8 text, JSON, binary bytes, or compressed data that cannot be displayed as readable text.
- Never infer trust from successful decoding. A decoded value can still be forged, expired, unsafe, or private.
Three practical examples
| Scenario | Sample input | What to check before copying |
|---|---|---|
| Simple UTF-8 text | Hello, 世界 | Encoding should preserve Unicode after a UTF-8 aware path; a Latin-1-only path may corrupt non-ASCII characters. |
| JWT payload segment | eyJzdWIiOiIxMjMiLCJyb2xlIjoiZGVtbyJ9 | Decode for inspection only. Do not treat a JWT segment as verified without validating the signature in the application. |
| Data URI fragment | data:image/svg+xml;base64,PHN2ZyB4bWxucz0iLi4uIj48L3N2Zz4= | Separate the metadata prefix from the encoded payload before decoding, and confirm the media type before reuse. |
Common error table
| Symptom | Likely cause | How to confirm | Practical fix |
|---|---|---|---|
| Invalid character during decode | The input contains whitespace, a data URI prefix, URL-safe alphabet characters, or a copied quote. | Look for characters outside A-Z, a-z, 0-9, +, /, = or the URL-safe - and _ variant. | Remove prefixes and surrounding quotes, then choose the correct Base64 variant. |
| Incorrect padding | The final = signs are missing or the input length is not compatible with Base64 groups. | Check the length modulo 4 and whether the source intentionally omits padding. | Restore padding for strict decoders or use a decoder that supports the unpadded variant. |
| Decoded text looks garbled | The bytes are not UTF-8 text, or a browser binary-string method was used on Unicode text. | Try to identify whether the output is an image, compressed file, or binary protocol. | Use binary-safe tooling for bytes and UTF-8 conversion for human-readable text. |
| Decoded JSON is visible but token still fails | Base64 decoding does not validate signatures, expiry, issuer, or audience. | Review the authentication library error, not only the decoded payload. | Validate the token with the correct key and claims in the application environment. |
| Space or line breaks cause intermittent failures | MIME wrapping, email clients, or rich-text copying inserted whitespace. | Compare the source value with a plain-text copy. | Normalize whitespace only when the protocol allows it, then decode again. |
Security and privacy boundary
A Base64 string can hide credentials in plain sight. Decoding it may reveal API keys, cookies, basic-auth values, signed links, or embedded documents.
- Treat unknown Base64 as potentially sensitive until decoded in a controlled context.
- Do not paste bearer tokens, session cookies, basic-auth headers, private data URIs, or customer exports.
- When preparing examples, replace real tokens and IDs with synthetic values that still demonstrate padding and alphabet behavior.
- Do not publish decoded JWT payloads unless the claims have been intentionally sanitized.
Technical reference notes
Base64 handling depends on the alphabet, padding rule, and text-to-byte conversion path. These references define the main boundaries used by modern web tools.
- RFC 4648 Base-N Encodings — standard Base64 alphabets, padding, and canonical encoding
- MDN Window.btoa() — browser Base64 behavior for binary strings
- Base64 encoding guide — local guide for text and API examples
Copy result checklist
- Identify whether the value is standard Base64, Base64URL, a JWT segment, or a data URI.
- Remove transport wrappers such as data: prefixes only after recording what they were.
- Check whether the decoded output is text, JSON, image data, compressed data, or another binary format.
- Do not describe Base64 as encryption in documentation or user-facing messages.
- Sanitize decoded content before sharing screenshots, examples, or support tickets.
- For authentication material, verify signatures and claims in application code rather than relying on a decoded view.
Related guides for deeper review
Editorial update: 2026-06-07. This Base64 page was reviewed for padding, Base64URL, Unicode, data URI, JWT-inspection, and privacy-boundary guidance so encoded values can be checked before copying.