Converter
Runs locallyBinary (base 2)
Hexadecimal (base 16)
Octal (base 8)
Decimal (base 10)
Ready. Type or paste text to see all four bases.
0x prefixes are ignored. 48 69 and 4869 both decode to Hi.
Decoded text
What this tool does
Every character you type is a number. Which number, and how it is written down, is a two-step decision: the character encoding decides the number, and the number base decides how to write it. This tool makes both steps visible. Paste text and see the same data as binary, octal, decimal and hex side by side. Or paste any of those bases and get readable text back.
It is aimed at people who need to see the underlying representation: reading a hex dump, checking a Unicode code point, verifying what a byte sequence actually decodes to, explaining number bases to someone learning, or producing a binary string for a puzzle or a specification. Everything runs in this browser tab. There is no upload, no account and no logging.
One design decision matters more than the rest and is worth stating plainly: binary and hex are derived from UTF-8 bytes, while octal and decimal are derived from Unicode code points. The next section explains why.
How the encoding works
A character like é can be represented three different ways depending on context, and confusing them is the source of most encoding bugs. This tool is explicit about which one it uses where.
Code points
A code point is one abstract character in Unicode, written as U+ followed by four to six hex digits. A is U+0041, é is U+00E9, 中 is U+4E2D, 😀 is U+1F600. Code points are the identity of a character. They do not have a fixed bit width — U+0041 needs 7 bits, U+1F600 needs 21 — which is why octal and decimal output is space-separated, one token per character.
UTF-8 bytes
A byte is exactly 8 bits. UTF-8 is a variable-length encoding that turns a code point into one to four bytes:
| Code point range | UTF-8 bytes | Example |
|---|---|---|
| U+0000 – U+007F | 1 byte | A → 41 |
| U+0080 – U+07FF | 2 bytes | é → C3 A9 |
| U+0800 – U+FFFF | 3 bytes | 中 → E4 B8 AD |
| U+10000 – U+10FFFF | 4 bytes | 😀 → F0 9F 98 80 |
Why binary and hex use bytes
A byte is exactly 8 bits or 2 hex digits. That fixed width is the whole reason binary and hex can be written without separators: you always know where one byte ends. A four-byte emoji becomes 32 bits — four groups of eight — and decoding is unambiguous. If binary were derived from code points instead, one character might need 7 bits and the next 21, and you could not tell where the boundary was without a separator.
48 54 54 50 and read HTTP, you are reading UTF-8 bytes. Deriving binary and hex from the same representation the wire uses is the honest choice.
Why octal and decimal use code points
Octal and decimal have no fixed-width convention — three octal digits and three decimal digits do not line up with anything meaningful. They are also space-separated in the output, so variable length costs nothing. Using code points here means a single character always produces a single token, which is what people expect when they ask "what is the code for 中?" The answer is 20013 in decimal, not a pair of numbers derived from a byte sequence.
What about UTF-16?
JavaScript engines store strings internally as UTF-16, and the old charCodeAt() API exposes that. A character above U+FFFF, including most emoji, is stored as a surrogate pair of two 16-bit code units. An earlier version of this tool used charCodeAt directly, which produced 15- and 16-bit chunks that broke the binary round-trip for anything outside ASCII. This version iterates by code point with Array.from(text) and encodes bytes with TextEncoder, so the output is consistent and round-trips exactly for every Unicode character.
The four bases
Binary (base 2)
Uses only 0 and 1. Binary is what a CPU's logic gates actually process — a transistor is either on or off. Every other base on this page is converted to binary before the hardware does anything with it. In code, binary literals are often written 0b01001000.
Octal (base 8)
Uses digits 0–7. Octal packs three binary bits per digit, which is why it was popular on early 12-bit and 36-bit machines. It survives today in two places: Unix file permissions and a handful of hardware register specifications.
Decimal (base 10)
The base humans use. Digits 0–9. Computers do not think in decimal, but almost every programming language displays numbers this way by default because readers expect it. When you ask for a character's "code point", the decimal form is usually what you get.
Hexadecimal (base 16)
Uses 0–9 plus A–F. Hex is the developer's preferred way to write bytes because a byte is exactly two hex digits. A hex dump of forty bytes is forty pairs of characters, aligned and readable. In code, hex literals are written 0x48.
| Byte | Binary | Octal | Decimal | Hex |
|---|---|---|---|---|
H | 01001000 | 110 | 72 | 48 |
i | 01101001 | 151 | 105 | 69 |
! | 00100001 | 41 | 33 | 21 |
For characters in the ASCII range, all four rows agree with what you would expect from any reference table, because ASCII is a subset of Unicode and single-byte in UTF-8.
Real-world use cases
Octal in Unix permissions
The chmod 755 form is octal because each digit encodes exactly three bits — read is 4, write is 2, execute is 1. The digit is never higher than 7 because that is the largest three-bit value.
755 = (4+2+1) (4+0+1) (4+0+1)
rwx r-x r-x
owner group others
Add the values in each position and you get the digit. That is the entire system.
Hex in memory debugging and hex dumps
When a program crashes and you look at a hex dump, you see raw memory rendered so that byte boundaries are visible. A pointer like 0x7ffd4a2e9b40 is far easier to compare visually than its 64-bit binary equivalent. When you inspect a network packet, bytes like 48 54 54 50 spell HTTP — that is the ASCII value of each letter in hex, one byte each.
Binary in bitmasks and flags
Whenever you see code like flags & 0b0100, you are using binary directly to test a single bit. Bitmasks power file permission systems, graphics rendering, protocol headers, and any API that packs several booleans into one integer.
Code points in text processing
Search, sorting, case folding and truncation all depend on knowing the code point of each character. "Truncate to 280 characters" is ambiguous: 280 code points, 280 UTF-16 code units, or 280 UTF-8 bytes? Twitter counts code points; a database column with a VARCHAR(280) typically counts bytes. This tool shows both numbers so you can see the difference.
Worked example: Hi! 😀
Five visible characters, but three different counts depending on what you are counting. Here is the exact output this tool produces.
Text Hi! 😀 Chars 5 (H, i, !, space, 😀) — counted as Unicode code points Bytes 8 (48 69 21 20 F0 9F 98 80) — UTF-8 Binary 01001000 01101001 00100001 00100000 11110000 10011111 10011000 10000000 Hex 48 69 21 20 F0 9F 98 80 Octal 110 151 41 40 373200 Decimal 72 105 33 32 128512
Notice the pattern in the first three characters: H and i differ only in a couple of bits, because ASCII was designed so that letters close together in the alphabet are close together numerically. Notice also that the emoji is one token in decimal (128512) but four tokens in hex (F0 9F 98 80). Same character, two representations, both correct for what they describe.
The round-trip check in the tool confirms that decoding the binary output gives back the original string, and the same for each other base. If a base ever fails the check, the tool says so rather than silently showing broken output.
Decoding rules
The second tab reverses the process. The rules differ by base because the output format differs.
| Base | Separator | Grouping | Example → Hi |
|---|---|---|---|
| Binary | Optional | 8 bits per byte | 01001000 01101001 or 0100100001101001 |
| Hexadecimal | Optional, 0x prefixes stripped | 2 digits per byte | 48 69 or 4869 or 0x48 0x69 |
| Octal | Required | One code point per token | 110 151 |
| Decimal | Required | One code point per token | 72 105 |
Binary and hex are decoded as UTF-8 with a fatal flag, so an invalid byte sequence produces a clear error rather than replacement characters. If the bit or digit count is not a multiple of the grouping size, the tool says how many bits or digits are missing instead of silently truncating — which is exactly the bug that made the previous version of this tool corrupt non-ASCII text.
What this tool cannot do
- It does not show individual characters. A per-character table with code point, UTF-8 bytes and all four bases is genuinely useful for debugging but is not part of this page yet.
- It does not convert arbitrary number bases. Only 2, 8, 10 and 16 are supported. Base64 and base32 are separate tools with different rules.
- It does not handle binary files. It works with text. For arbitrary bytes, use a hex editor.
- It does not decode Latin-1 or Windows-1252. Binary and hex input is always interpreted as UTF-8. A legacy-encoded byte sequence may decode to replacement characters, and the tool will tell you it could not decode rather than guessing.
- It does not verify a checksum or a hash. If you need that, the hash generator is a separate tool.
- It does not preserve your input between visits. There is no autosave. Copy or download before closing the tab.
Frequently asked questions
How does text to base conversion work?
Every character has a numeric value. Binary and hexadecimal output is derived from the UTF-8 byte sequence of your text, one byte at a time. Octal and decimal output is derived from the Unicode code point of each character. Both are just different ways of writing down the same underlying data.
How do I convert binary back to text?
Switch to the Bases → Text tab, choose Binary, and paste your binary string. Whitespace is ignored, so spaces and line breaks are optional. The tool groups the bits into 8-bit bytes and decodes them as UTF-8. If the bit count is not a multiple of eight, the tool says so instead of silently discarding the remainder.
Why does binary output use UTF-8 bytes rather than UTF-16 code units?
A byte is exactly eight bits or two hex digits, which gives binary and hex a fixed width per unit. That fixed width is what makes them decodable without separators. UTF-16 code units do not have a fixed width: most ASCII characters are 16-bit, but surrogate pairs for emoji are also 16-bit and mean something different. Using UTF-8 bytes removes that ambiguity and matches what the network, your files and your database actually store.
Are spaces and punctuation converted?
Yes. Every character has a value, including spaces, tabs, newlines, punctuation and emoji. A space is U+0020 in Unicode and 0x20 as a UTF-8 byte, so it appears in the output like any other character.
Is my text sent to a server?
No. Encoding and decoding run in JavaScript on your device. There is no API call and no analytics event containing your text. You can confirm this in the Network tab: type a paragraph and check that no request appears. The page also keeps working with the network disconnected after it loads.
What does the Total bits statistic mean?
It is the length of the binary output for your text, which equals the number of UTF-8 bytes multiplied by eight. It is not the number of bits needed to store the string in memory: a JavaScript engine stores the string internally as UTF-16, so the memory footprint is roughly double for pure ASCII. The statistic describes the binary representation on this page, not the RAM usage.
What are octal permissions in Unix, such as chmod 755?
Unix file permissions use octal because each digit encodes exactly three bits: read is 4, write is 2, execute is 1. So 755 means the owner gets 4+2+1=7 (read, write, execute), and the group and other each get 4+0+1=5 (read, execute). That is why the digit is never higher than 7 — the largest three-bit value.
Why do hex dumps and memory addresses use hexadecimal?
Because a byte maps to exactly two hex digits. A hex dump of forty bytes is forty pairs of characters, aligned and readable. The same data in binary would be 320 ones and zeros with no natural grouping. A pointer like 0x7ffd4a2e9b40 is also far easier to compare visually than its 64-bit binary equivalent.
About this tool
Editorial and verification standards are in the editorial policy. Data handling is in the privacy policy.