Hex / Binary / Text Converter

Convert text to and from hexadecimal and binary representations.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Shows the bytes behind your text — hexadecimal or binary, one space-separated group per byte — and reads those groups back into text again, so you can inspect or hand-assemble a byte sequence without a hex editor.

How to use it

1Pick a direction in the Mode dropdown: Text → Hex, Hex → Text, Text → Binary or Binary → Text.
2Type or paste into the Input box; the Output box fills in as you type, and anything malformed reports its own error instead.
3Use Copy to take the result.

Example

Input: café
Output: 63 61 66 c3 a9

Five bytes for four letters: encoding is UTF-8, so é is c3 a9. Going the other way, whitespace anywhere in the input is stripped before decoding, but an odd number of digits stops with "Hex input must have an even number of digits", and binary must come in whole 8-bit groups.

What happens to your data

Conversion is done by the browser's built-in TextEncoder and TextDecoder — the same pair your own JavaScript would use — inside a useMemo that re-runs on each keystroke. Nothing is buffered between runs: an input that fails validation produces an error string and an empty output box rather than a partial result, and the text exists only in one component state variable that a reload clears.

Last updated August 2026

The value came back as a run of hex pairs — out of a database column, a log line, a diff that keeps flagging a row which looks identical to the one above it — and you need to know what is actually in there. Two strings can render the same on screen and hold different bytes, and hex is where that difference stops hiding.

Before you paste anything, work out which kind of hex conversion you are after, because the word covers two unrelated jobs. One is notation: writing a single number in base 16, so 255 becomes ff and 4096 becomes 1000. The other is encoding: taking a piece of text, working out the bytes it is stored as, and printing each of those bytes as two digits. This page does the second. If you are moving one number between bases, the number base converter is the tool for that — put it in here and you will get the bytes of the digits you typed rather than the value they stand for.

The limitation worth knowing in advance is that hex records bytes and nothing else. It does not record which encoding produced them, so the same accented letter is e9 in Latin-1 and c3 a9 in UTF-8, and nothing in the digits tells you which one you are holding. Both directions here assume UTF-8, with no switch for anything else.

The common mistake follows from that: counting hex pairs as though they were characters. One byte is always two digits, but one character is not always one byte — which is how a name that fits a twenty-character field is still refused by a twenty-byte column.

How it works

Toolvore encodes your text with the browser's own UTF-8 encoder and prints every byte at a fixed width — two hex digits, or eight binary digits, padded with leading zeros — joined by single spaces, so a group on screen is always one byte and never one character. Going the other way, whitespace is stripped out first, which means a sequence pasted across several lines or separated by tabs converts unchanged; then the whole string is validated before a single byte is parsed, which is why one stray character rejects the entire input instead of decoding the good part and stopping where it broke. Length is checked as well: hex must be an even number of digits, binary must divide into whole groups of eight, because half a byte is not a byte. The weak point is the return trip. Decoding is non-fatal, so bytes that are not valid UTF-8 are not refused — each bad sequence is swapped for the U+FFFD replacement character, and once that swap has happened the original bytes are gone. Encode the result again and it will not match what you started with. There is also no file picker, only what you can type or paste.

Common use cases

Checking whether an invisible character in a CSV is a non-breaking space or an ordinary one
Seeing how many bytes an emoji or an accented name costs against a byte-limited column
Reading a short hex string out of a log line back into words
Hand-assembling a byte sequence for a test fixture or a protocol frame
Showing a class what a single letter looks like as eight bits
Working out why a name arrived as mojibake after passing through another system
Comparing two strings that look identical on screen but behave differently

Frequently asked questions

What is hexadecimal, and why are bytes written in it?＋

A byte holds a value from 0 to 255, and base 16 fits that whole range in exactly two digits, 00 through ff, because sixteen is two to the fourth — each digit stands for four bits and each pair for eight. Decimal cannot do that: 255 needs three digits and 7 needs one, so a run of them has no visible boundary. Hex gives every byte the same width, which is what makes a dump readable in columns and makes a missing byte obvious. The digits run 0 to 9 then a to f, where a is ten and f is fifteen. Case carries no meaning at all — ff and FF are the same byte.

Why does one character sometimes take more than two hex digits?＋

Because UTF-8 is a variable-length encoding. The 128 characters of ASCII — unaccented Latin letters, digits, ordinary punctuation — take one byte each, so for plain English text one character really does come out as one pair. Everything else costs more: most accented, Greek and Cyrillic letters take two bytes, most Chinese, Japanese and Korean characters take three, and emoji take four. Some emoji are longer still, because what looks like a single image is several code points welded together with an invisible zero-width joiner, each encoded separately. That gap is why a message that passed a limit counted in characters can overflow the same limit counted in bytes.

What is the difference between hex and Base64?＋

Both turn bytes into printable characters, and they differ in what that costs. Hex uses sixteen symbols and spends two per byte, so the encoded form is twice the size of the data. Base64 uses sixty-four symbols and packs three bytes into four characters, so it grows by about a third. The trade is readability. In hex you can point at any pair and read the byte's value, which is why hashes, colour values, MAC addresses and memory dumps are written that way. Base64 tells your eye nothing but is far more compact, which is why it carries email attachments, images embedded in stylesheets, and keys inside configuration files.

Why is my hex string rejected when it starts with 0x?＋

The 0x prefix is a convention from programming languages marking a literal as base 16. It is not part of the number and x is not a hex digit, so validation refuses the input with a message about non-hex characters rather than quietly ignoring it. The same applies to commas between pairs, semicolons, backslash-x escapes and the h suffix assemblers use. Spaces, tabs and line breaks are the one exception — they are stripped before anything is checked, so a sequence split across several lines needs no tidying. Remove the rest by hand and the digits underneath convert normally.

Where does my text go — is any of it uploaded?＋

None of it leaves the page. There is no upload control and no file picker, and typing makes no network request: the conversion is arithmetic on a string the browser already holds, done by encoder and decoder objects built into the browser itself. Your text sits in one piece of component state, and the output is recalculated from it rather than kept anywhere separate, so closing or reloading the tab is enough to be rid of both. That matters when what you are inspecting is a token, a key fragment or a customer record — precisely the strings people paste into online converters without thinking about it.

Why does my decoded text come back as black diamonds with question marks?＋

That symbol is U+FFFD, the replacement character. It means the decoder met a byte sequence that is not valid UTF-8 and substituted a marker instead of failing outright. It usually points to one of three things: the bytes were never text, they were text in another encoding such as Latin-1 or Windows-1252, or a multi-byte character was cut in half when the string was copied. The substitution cannot be undone — encode that output again and you get the bytes of the replacement character, not the ones you began with. If a different encoding is the likely cause, take the original bytes to a converter that lets you name it.

How do I convert hex to binary?＋

One digit at a time, with no arithmetic across boundaries: each hex digit is exactly four bits, so f is 1111, a is 1010 and 3 is 0011, and a hex string becomes binary by replacing every digit with its four bits. That direct correspondence is the reason the two notations are so often used side by side. Here they are not wired to each other, though. The four modes run between text and hex and between text and binary, so a hex string reaches binary by way of text — which only works if those bytes happen to be valid text to begin with.

How do I see the contents of a file in hex?＋

You want a hex viewer rather than a text converter, because most of a file's bytes are not typeable characters and pasting them into a text box loses them. On macOS and Linux, xxd or hexdump -C prints offsets, hex and an ASCII column side by side; on Windows, certutil -dump or a dedicated hex editor does the equivalent. Those tools also let you jump to an offset, which is how people check a file signature — the first few bytes identifying a format, such as 25 50 44 46 at the start of a PDF. This page accepts typed or pasted text only, with no file input of any kind.