Text to Binary

The tool covers 24 directed conversions across six representations: plain text, ASCII decimal codes, binary, decimal, hexadecimal and octal. They form 12 reversible pairs — text/binary, text/hex, text/octal, text/decimal, binary/hex, binary/octal, binary/decimal, binary/ASCII, hex/decimal, hex/octal, octal/decimal and ASCII/text — so every conversion has a working inverse behind the Swap button. Converter view gives one large input, a full output pane and a dropdown listing all 24 with descriptions. By Category groups them into the 12 pairs and collapses the rest when you click a heading. All Tools puts every converter on screen as an independent card with its own input, output and copy button, filtered by a search box. Most competing pages ship one conversion per URL; this is one URL, no reload between conversions, and no daily usage cap.

Numeric base conversions run through JavaScript BigInt, so there is no precision cliff. Decimal to Binary, Binary to Decimal, Hex to Decimal, Decimal to Hex, Octal to Decimal, Decimal to Octal, Hex to Octal and Octal to Hex parse via BigInt('0b…'), BigInt('0x…') or BigInt('0o…') and return exact results for integers of any length. A 128-bit UUID as hex, a 512-bit key or a 200-digit decimal converts without rounding. Converters built on parseInt or Number lose accuracy above 2^53 − 1 with no warning, and some popular tools cap binary-to-decimal input at 63 characters. Hex to Binary, Octal to Binary, Binary to Hex and Binary to Octal work digit-by-digit on strings, so they are unbounded too. The limits are narrow but real: unsigned integers only — no minus sign, no fractional part, and a decimal input must be one unbroken run of digits.

Every conversion is a pure function executing in your tab: a string goes in, a string comes out, and no fetch, XHR or WebSocket ever carries your input anywhere. There is no account and no upload step. The only requests the page makes are for its own JavaScript — the Category and All Tools cards load the conversion module as a dynamic import on first use, which ships code, not your data. Copying uses navigator.clipboard.writeText in a secure context. Downloading builds a Blob locally and hands it to URL.createObjectURL, so saving output never leaves the machine either. Nothing is written to localStorage, sessionStorage or cookies. That matters when the bytes you are decoding came from a production packet capture, a firmware dump or a customer record — pasting those into a server-side converter is a disclosure you cannot take back.

Settings, behind the gear icon in Converter view, controls four things. Binary Group Size re-chunks binary output into 4, 8, 16 or 32 bits: 4 lines up with one hex digit, 8 with one byte, 32 with a word. HEX Group Size chunks hexadecimal output into 2, 4 or 8 characters. Uppercase HEX output, on by default, toggles between FF and ff. Auto convert on input can be switched off if you would rather press Convert yourself. Grouping is applied after conversion and only in Converter view; the inline cards in Category and All Tools views show the raw result. Binary, hex and octal input has whitespace stripped before parsing, so a binary block copied from a protocol table or hex copied from a dump pastes straight in — decimal input is the one format that must arrive as a single unbroken number.

Text conversions read UTF-16 code units through charCodeAt, not UTF-8 bytes. Everything from U+0000 to U+00FF — the full ASCII and Latin-1 range — encodes to exactly 8 bits and round-trips cleanly. Above that the output grows past one byte per character, and astral-plane characters such as emoji are read from their first surrogate only, so a 😀 comes back as D83D and will not decode. Binary to Text and Hex to Text reverse the process by mapping each 8-bit group to one character code, which is Latin-1 semantics: UTF-8 encoded é (C3 A9) returns as two characters. Validation is strict per format — 0 and 1 for binary, 0-7 for octal, 0-9 and A-F for hex, 0-255 for ASCII to Binary — and bad input raises a named error toast instead of a silently wrong answer.

No. Every conversion is a pure JavaScript function running in your tab. Text to binary calls charCodeAt and toString(2); numeric base conversions call BigInt. Your input is never part of a network request — there is no fetch, XHR or WebSocket carrying it, and no account. Download builds a Blob locally and passes it to URL.createObjectURL, so saving the result never touches a server either. The only network activity the page can produce is loading its own JavaScript: in the Category and All Tools views the first Convert click dynamically imports the conversion module chunk. That request contains code, never your text.

The text is split into code points, each one is read as a UTF-16 code unit with charCodeAt(0), converted to base 2 with toString(2), then left-padded to 8 bits with padStart. The letter H is code point 72, which is 1001000 in binary and 01001000 once padded to a full byte. Groups are joined with a space. Hello becomes 01001000 01100101 01101100 01101100 01101111 — five bytes, 40 bits. Any character above U+00FF needs more than 8 bits, so padStart does nothing and that group comes out longer than one byte.

There is no ceiling and no input length cap. Decimal to Binary, Binary to Decimal, Hex to Decimal, Decimal to Hex, Octal to Decimal, Decimal to Octal, Hex to Octal and Octal to Hex all route through JavaScript BigInt, so they stay exact for integers of any length — a 200-digit decimal or a 512-bit key in hex converts without rounding. Converters built on parseInt or Number silently lose accuracy above Number.MAX_SAFE_INTEGER (2^53 − 1 = 9007199254740991), and some popular tools cap binary-to-decimal input at 63 characters. Hex to Binary, Octal to Binary, Binary to Hex and Binary to Octal work digit-by-digit on strings, so they are unbounded too.

Not reliably. Conversion works per UTF-16 code unit, not per UTF-8 byte. Characters from U+0000 to U+00FF — the full ASCII and Latin-1 range — encode to exactly 8 bits and round-trip cleanly. Above that, an astral-plane character such as 😀 (U+1F600) is read from its first surrogate only: charCodeAt(0) returns 0xD83D, so you get 1101100000111101 in binary or D83D in hex, and it will not decode back. Binary to Text also splits input into 8-bit groups and maps each to one character code, which is Latin-1 behavior rather than UTF-8 decoding. Use it for ASCII, protocol bytes and numeric data.

Binary to Text and Binary to ASCII left-pad the cleaned input with zeros up to the next multiple of 8 using padStart, then split it into 8-bit bytes. Binary to Hex pads to the next multiple of 4, since one nibble maps to one hex digit, and Binary to Octal pads to the next multiple of 3, since one octal digit covers 3 bits. Padding is always on the left, so the numeric value is preserved. Binary, hex and octal input has all whitespace stripped first, so data copied from a spec table or hex dump needs no cleanup. Decimal input is the exception: it must be one unbroken run of digits.

It controls how binary output is chunked for readability, not the conversion itself. The output string is stripped of its original spacing and re-chunked at 4 bits (one nibble, matching one hex digit), 8 bits (one byte, the default), 16 bits or 32 bits, joined by a space. HEX Group Size does the same for hexadecimal output at 2 characters (one byte, the default), 4 or 8. A separate checkbox, on by default, switches hex output between uppercase FF and lowercase ff. Grouping applies only in the main Converter view; the inline cards in Category and All Tools views show the raw unformatted result.

Yes. Octal to Binary expands each octal digit into exactly 3 bits, which is how POSIX mode bits are laid out: 755 produces 111101101 — 111 101 101, owner rwx, group r-x, other r-x. 644 gives 110100100 and 777 gives 111111111. Note that the Converter view re-chunks that string into your chosen group size, so at the default 8 bits 755 displays as 11110110 1; read the raw string in All Tools view if the byte grouping gets in the way. Octal to Decimal on 755 returns 493, the number os.chmod expects without the 0o prefix. Input is validated against digits 0-7, so a typo like 758 is rejected.

Hex to Text maps every two hex characters to one character code with parseInt(byte, 16) and String.fromCharCode. Bytes below 0x20 are ASCII control characters — 0x00 NUL, 0x09 tab, 0x0A line feed — and render as nothing or as replacement glyphs. Bytes from 0x80 to 0xFF are read as Latin-1, so UTF-8 encoded text appears as mojibake: é encoded in UTF-8 is C3 A9 and decodes here as the two characters à and ©. An odd number of hex digits is left-padded with a single zero before pairing, and a leading 0x prefix is stripped automatically.

No. Auto convert is enabled by default and fires 150 ms after you stop typing, re-running on input changes, conversion-type changes and formatting changes. You can turn it off with the "Auto convert on input" checkbox in Settings and use the Convert button instead. The debounce timer is cleared on every keystroke, so holding a key down or pasting a large block runs exactly one conversion. Because conversion is synchronous JavaScript with no network round-trip, that 150 ms debounce is the only latency between typing and seeing output. The Convert button stays disabled while the input is empty.

Swap flips to the inverse conversion. It splits the current type on the -to- separator, rebuilds it reversed and confirms the reversed type exists, so Text to Binary becomes Binary to Text and HEX to Octal becomes Octal to HEX. The current output is moved into the input box and the output pane is cleared, letting you verify a round-trip immediately. All 24 conversions form 12 reversible pairs, so every type has a valid inverse. The button is disabled until there is output to move.

No — they return identical output and share an implementation, since textToDecimal delegates to textToAscii. Both emit the decimal character code of each character, space separated: Hello gives 72 101 108 108 111. Both names exist because developers search differently, saying ASCII code when working from a character table and decimal when working across number bases. The same applies to ASCII to Text and Decimal to Text. One real difference sits in validation: ASCII to Binary rejects any code above 255, while ASCII to Text and Decimal to Text accept up to 65535, the full UTF-16 code unit range.

Yes, three ways, all local. Copy output writes to the clipboard through navigator.clipboard.writeText when the page is in a secure context, falling back to a hidden textarea and document.execCommand('copy') otherwise. Download builds a Blob with MIME type text/plain and saves it as the conversion type plus a millisecond timestamp — for example text-to-binary-1753500000000.txt — then revokes the object URL. Copy input does the same for what you typed. Nothing persists between reloads: the page writes no localStorage, no sessionStorage and no cookies, so refreshing the tab clears your input, output and settings.