Convert Octal to UTF-8

0 through 0377 (decimal 0-255) – one byte. Each octal value in the input represents one UTF-8 byte. For ASCII characters (decimal 0-127), one byte = one character. For multi-byte characters (accented Latin, CJK, emoji), two or more consecutive bytes combine to form one Unicode character; the tool’s TextDecoder handles the assembly automatically.

UTF-8 uses a self-synchronizing scheme: the lead byte’s value tells you how many continuation bytes follow. Bytes 0xC0-0xDF (octal 300-337) lead a 2-byte sequence; 0xE0-0xEF (octal 340-357) lead 3-byte; 0xF0-0xF7 (octal 360-367) lead 4-byte. Continuation bytes are always in the 0x80-0xBF (octal 200-277) range. The decoder spots them automatically – you just paste the octal bytes in order.

Strict mode (using TextDecoder({fatal: true})) throws an error on any byte sequence that isn’t valid UTF-8 – useful for verifying your input is clean. Replace mode substitutes � (U+FFFD, the Unicode replacement character) for each invalid sequence – useful for graceful recovery from corrupted data. Keep mode bypasses UTF-8 decoding entirely and treats each byte as its Latin-1 character – useful when your data is actually Latin-1 not UTF-8.

It matches the literal escape sequence syntax in C, C++, Python, and most languages descended from C. In source code you’d write a string like "303251" and the compiler/interpreter reads those three-digit octal escapes as raw bytes. Paste your decoded result into a string literal and the compiler reproduces the original characters. Same goes the other way for round-tripping.

UTF-8 multi-byte sequences have one “lead” byte (range C0-FD) followed by 1-3 “continuation” bytes (range 80-BF). The lead byte declares “I’m starting a 2/3/4-byte character”. The continuation bytes contribute the rest of the codepoint’s bits. Visually we dim the continuations to make it obvious which bytes form which character – useful for spotting where a multi-byte sequence starts and ends.

Sort of. In Strict mode, no – invalid bytes throw an error. In Replace mode, invalid sequences become � but valid surrounding text still decodes fine. In Keep mode (Latin-1), every byte becomes some character – even invalid UTF-8 bytes get a rendering (often a control character or accented Latin glyph). Pick Keep when your “octal” is actually a non-UTF-8 byte stream you want to inspect byte-by-byte.

Uses the browser’s TextEncoder API which always emits UTF-8 bytes. Each byte then gets formatted as a 3-digit octal (always padded to 3 digits, even for ASCII). So “Hello” becomes 110 145 154 154 157 (5 bytes). For non-ASCII: “é” becomes 303 251 (2 bytes); “😀” becomes 360 237 230 200 (4 bytes).

C/C++/Python string literals ("303251"), some older Unix protocol dumps, octal-formatted register exports from embedded systems, and certain database export formats. The convention pre-dates hex’s dominance in modern systems but persists in C-family ecosystems for backwards compatibility.

No. All parsing, byte arithmetic, and UTF-8 decoding/encoding runs in your browser using the built-in TextEncoder/TextDecoder APIs. Open DevTools → Network and confirm zero requests fire after the page loads.

Yes. Total bundle is under 22 KB. Once loaded, disconnect and keep converting. Useful for sysadmin work or legacy data recovery on air-gapped boxes.