Convert text between UTF-8, Base64, and hexadecimal
Base64 and hexadecimal are reversible text representations of bytes. They help move data through systems that expect printable characters, but they do not provide secrecy, authenticity, or access control.
The converter is suited to ordinary UTF-8 text and encoded strings that fit comfortably in browser memory. It is not a streaming binary-file encoder and should not be used to conceal passwords, tokens, or private records.
Text becomes bytes before it becomes Base64 or hex
Characters need an encoding such as UTF-8. The same visible text represented in a different character encoding can produce different bytes and therefore different Base64 and hexadecimal output.
Emoji and non-Latin characters use multiple UTF-8 bytes. Count bytes rather than visible characters when a protocol imposes size limits.
Base64 trades compact binary for printable text
Base64 represents groups of bytes with a 64-character alphabet and optional padding. It is useful in JSON, email, data URLs, and protocols that cannot carry arbitrary binary safely.
The representation is roughly one third larger than the binary input. URL-safe variants replace some alphabet characters and may omit padding, so a decoder must know which convention is expected.
Hex is simple and verbose
Each byte becomes two hexadecimal digits. That makes byte boundaries easy to inspect, but doubles the size compared with raw bytes.
Prefixes such as 0x, spaces, separators, and uppercase letters are presentation conventions. Confirm what the destination accepts before removing or adding them.
Decoded content remains untrusted
Decoding does not make a value safe. The result might contain HTML, a script, a command, a URL, or malformed binary intended to exploit the next parser.
Inspect and validate decoded data for its destination. Use encryption and authenticated access controls when secrecy or tamper resistance is required.
Use byte-level examples to diagnose Unicode surprises
When an encoded value does not round-trip, reduce the input to a short example that includes one plain ASCII character and one non-ASCII character such as an accented letter or emoji. Encode it, inspect the UTF-8 bytes in hexadecimal, and then compare those bytes with the system that produced the other value. This exposes whether one side used UTF-8, UTF-16, a legacy code page, or raw binary data. Check Base64 padding and URL-safe alphabet substitutions separately. Never assume decoded bytes are harmless text: save or execute them only when the source is trusted and the expected file type is understood.
Quick start: LocalUtils
- Identify whether the source is plain UTF-8 text, Base64, or hexadecimal before choosing a direction.
- Paste a small known sample and convert it once.
- Reverse the conversion and compare the recovered text or bytes with the original.
- When using the result in another system, confirm its alphabet, padding, byte encoding, and expectations for line breaks or prefixes.
What the browser does
The browser converts text to UTF-8 bytes and represents those bytes as Base64 or hexadecimal. Decode operations reverse the representation and interpret recovered bytes as text.
No encryption key is involved. Anyone with the encoded value can normally decode it. The text stays in the browser utility path but can remain in clipboard history or browser-managed form state after use.
Inputs and outputs
- Text input and output use UTF-8 expectations.
- Base64 uses the standard alphabet and may include equals-sign padding.
- Hexadecimal requires pairs of valid hex digits representing bytes.
Limits to know before you start
- Arbitrary binary data may not decode to meaningful UTF-8 text.
- URL-safe Base64 variants can use different characters and padding rules.
- Odd-length or non-hex characters make hexadecimal invalid.
- Large values expand in Base64 or hex and can make a text-area workflow inefficient.
Verification checklist
- Round-trip a known sample through encode and decode.
- Compare byte length and exact characters, including whitespace.
- Treat every decoded value as untrusted input before placing it in HTML, a command, or a program.
Troubleshooting
- If Base64 decoding fails, remove surrounding labels and check whether the source uses a URL-safe alphabet.
- If text is garbled, confirm the original byte encoding rather than assuming UTF-8.
- If hex fails, remove spaces or prefixes only when the destination format does not require them and confirm an even digit count.
Questions people ask
Can someone decode Base64 without permission?
Yes. No secret is required, and widely available tools can reverse it immediately.
Why does decoded text look corrupted?
The recovered bytes may use another text encoding or may be arbitrary binary rather than text.
When should I use hex instead?
Hex is convenient for byte-level inspection, digests, protocol fields, and short binary values where readability matters more than size.