Text to hex conversion produces the same UTF-8 byte sequence whether you run xxd in a terminal or paste text into a browser-based encoder, and the difference lies in where the bytes are processed, what output syntax the tool produces, and how Unicode edge cases are surfaced. Both paths start from the same WHATWG Encoding Standard rule that maps every Unicode scalar to one to four UTF-8 bytes, and both end with a hexadecimal string that anyone holding the bytes and the UTF-8 rules can read. The choice between them is therefore about workflow, environment, error reporting, and format options rather than about which path is right in absolute terms. Picking the wrong path usually costs time: command line tools reward shell fluency and tight pipelines but offer little feedback on malformed input, while online encoders give clearer counts and warnings but add clipboard steps. The rest of this article walks through both paths so you can decide which one fits the task in front of you, then shows the exact three-step flow inside Text To HEX when an online encoder is the better fit.
What Command Line Tools Actually Do for Text to Hex
Command line tools such as xxd, od, hexdump, and printf convert text by piping bytes from a file or stream through a hex formatter. xxd is the canonical choice on Linux because it accepts a plain string argument with the -ps flag and prints continuous lowercase hex pairs; `echo -n "Hi" | xxd -ps` prints 4869. od is the POSIX-standard alternative with -An -tx1 for one byte per token, and hexdump on BSD behaves similarly. Each of these tools runs entirely on the local machine, never sends text to a remote server, and produces the byte sequence that the kernel hands it through stdin. That last clause matters: shell encoding defaults, locale variables like LANG and LC_CTYPE, and the shell's own quoting rules can shift the bytes before the tool ever sees them, which is the most common cause of mismatched hex output in command line workflows.
The output syntax is fixed by each tool. xxd with -ps emits continuous pairs, xxd with -p prints the same pairs followed by a trailing newline, and od with -tx1 prints space-separated bytes. None of them offer a 0x-prefixed mode, none of them warn about isolated UTF-16 surrogates, and none of them count how many bytes you actually got. If you want uppercase A through F you need a flag (-u in some forks) or a downstream tr command. For round trips, command line tools also cannot tell you whether the bytes you encoded will decode back to identical text under a strict decoder, so any check of "did the bytes round-trip?" requires running the inverse tool and comparing manually.
Common Command Line Tools Side by Side
Below is a comparison of the most widely used command line tools for text to hex encoding. The table lists the canonical invocation pattern, output syntax, and a practical note for each. The byte values shown for the sample input "Hi" are illustrative of each tool's syntax; the exact output for your input always comes from running the tool yourself.
| Tool | Common invocation | Output syntax | Practical note |
|---|---|---|---|
| xxd | echo -n "Hi" | xxd -ps | Continuous lowercase pairs (4869) | Fastest path on Linux; add -u to uppercase A through F; no 0x prefix option. |
| xxd -p | echo -n "Hi" | xxd -p | Continuous pairs with trailing newline | Same bytes, just adds a newline at the end of the dump. |
| od | echo -n "Hi" | od -An -tx1 | Space-separated bytes (48 69) | POSIX-portable alternative when xxd is not installed. |
| hexdump -C | echo -n "Hi" | hexdump -C | Canonical hex+ASCII display | Best for inspection, awkward for piping bytes downstream. |
| printf + od | printf 'Hi' | od -An -tx1 | Space-separated bytes | Useful when echo's trailing newline would change the byte count. |
| perl -e + od | perl -e 'print "Hi"' | od -An -tx1 | Space-separated bytes | Handy when the shell mishandles non-ASCII characters or quoting. |
None of the entries above adds a UTF-8 BOM, and all of them produce the same byte sequence for the same input, provided the shell passes the bytes through unchanged. Locale problems are the usual culprit when these tools appear to give different hex for the same visible character.
How to Convert Text to Hex with an Online Tool
Online encoders remove the locale problem by using the browser's built-in TextEncoder API, which always operates on the JavaScript string as UTF-16 internally and converts it to UTF-8 bytes per the WHATWG Encoding Standard. The browser handles encoding consistently, regardless of the host operating system, so the same string typed into Text To HEX on Windows, macOS, or Linux produces identical bytes. The tool below is one example of that pattern: enter text, pick a format, copy the result.
- Enter text, including any Unicode, whitespace, or NUL data that the browser field can hold.
- Choose continuous pairs such as 4869, space-separated bytes such as 48 69, or per-byte tokens such as 0x48 0x69, and select lowercase or uppercase hexadecimal digits.
- Encode, review byte and replacement counts, then copy the complete hexadecimal output.
That three-step flow mirrors the manual command line pipeline (text in, bytes out, copy result) while giving you two things command line tools rarely offer: a counted replacement warning for isolated UTF-16 surrogates, and a choice between continuous, spaced, and 0x-prefixed output without piping through additional tools. For readers who need an exact, byte-for-byte result that round-trips through a strict UTF-8 decoder such as the companion Hex to Text Converter, the byte count and replacement count tell you whether the encode was lossless before you copy anything.
UTF-8 Edge Cases Command Line Tools Often Miss
UTF-8 sizing follows the same rules in any compliant encoder: ASCII characters use one byte, common Latin characters such as é use two, most BMP characters such as 你 use three, and supplementary scalars such as 😀 (U+1F600) use four. Concretely, U+0041 becomes 41, U+00E9 becomes c3a9, U+4F60 becomes e4bda0, and U+1F600 becomes f09f9880. Command line tools follow these rules as long as the bytes reaching them are valid UTF-8, but they give no feedback when an isolated UTF-16 surrogate appears in the input; they simply substitute the standard U+FFFD replacement (EF BF BD) and continue.
Three other behaviors are easy to miss in a command line workflow. First, the WHATWG TextEncoder adds no BOM, so ordinary input begins with the first character's bytes; if the input itself begins with U+FEFF, those bytes appear as EF BB BF because they are data, not metadata. Second, isolated surrogates are not Unicode scalars, so any well-defined encoder replaces them with U+FFFD before emitting bytes. Command line tools do this silently, while Text To HEX shows the replacement count so the loss is visible. Third, combining sequences stay decomposed unless the input was already composed, so e followed by U+0301 becomes 65 CC 81 rather than being silently collapsed to U+00E9. None of these are bugs; they are the standardized behavior that the WHATWG Encoding Standard mandates for any compliant UTF-8 encoder.
Privacy, Limits, and Choosing the Right Path
Privacy is the clearest case for choosing one path over the other. Both command line tools and a browser-based encoder that runs entirely client-side (such as Text To HEX) keep text and output local, so no bytes leave the machine. The risk only appears with server-backed online converters that POST the input to a remote API for encoding; those services see the plaintext and may log it. Command line tools avoid that risk entirely, but they trade away format choices and explicit counts. Browser-side encoders avoid it as well, while exposing continuous, spaced, and 0x-prefixed output and visible replacement counts. For readers handling credentials, tokens, or proprietary payloads, the deciding question is whether the chosen online tool runs in the browser tab; the user-visible difference between "runs locally" and "POSTs to a server" is the difference between private and not. A deeper privacy walkthrough is covered in Is Text to Hex Safe to Use Online? A Privacy Guide.
Limits differ between the paths as well. Command line tools are bounded by file size, disk space, and the shell's command line length, which on most Linux shells defaults to ARG_MAX around 2 MB. Browser encoders apply their own explicit budgets, which the WHATWG and MDN documentation do not standardize; each tool picks its own. Text To HEX, for example, accepts at most 1,000,000 UTF-16 code units of input and at most 4,999,999 UTF-16 code units of formatted output, and rejects anything over the limit with an explicit message rather than silently truncating. That boundary is exact: one million ASCII input characters in 0x-prefixed format produces exactly 4,999,999 output code units, and the tool enforces it before building the large formatted string.
The practical decision tree is short. Use the command line when text is already on disk, when you need to pipe bytes into another tool, or when no browser is available. Use a browser encoder like Text To HEX when you need explicit format choices, replacement warnings, byte counts, or when the input lives in a clipboard or chat window. Use whichever you trust to keep the bytes local. For command line that is always the case, and for online tools that is true only when the tool explicitly runs in the browser.
For a deeper look, see Base32 Decode: How Five-Bit Groups Rebuild UTF-8 Text.