A Unicode scalar value is the integer between U+0000 and U+10FFFF (excluding the U+D800βU+DFFF surrogate interval) that names one character in the Unicode standard, and char-code lookup is the workflow of getting those numbers for any string you can paste or type. Command-line lookup usually leans on utilities such as man ascii, python3 -c "print(hex(ord(...)))", perl one-liners, printf with %x, hexdump, xxd, or shell pipelines that print one numeric code per line. Online lookup, in this context, means a browser tool such as the Unicode Encoder / Decoder, which converts text into a space-separated sequence of U+ tokens without splitting supplementary-plane characters and runs entirely on your machine. The two paths answer the same diagnostic question β which abstract characters does this string actually contain β but they trade portability for full Unicode coverage in opposite directions: CLI pipelines stay close to ASCII and Linux userland, while a browser scalar converter reaches the same conclusion for emoji, accented letters, CJK, and joined sequences such as π©βπ» without leaving the tab.
Command-line ways to look up char codes
Linux and macOS ship with several utilities that double as ASCII or Unicode lookup tables. The simplest is man ascii, which prints the printable 7-bit range (0β127) with decimal, octal, and hexadecimal columns side by side. It is fast, offline, and preinstalled almost everywhere, but it stops at the basic Latin block.
For ad-hoc lookups you can lean on any scripting language that is already installed. In Python 3, python3 -c "print(hex(ord('Γ©')))" prints 0xe9, and a one-liner such as python3 -c "print(', '.join(f'U+{ord(c):04X}' for c in 'cafΓ©'))" produces a clean U+ stream for every scalar in the string. Perl does the same with perl -CSDA -e 'printf "U+%04X\n", ord for split //, "cafΓ©"'. Both commands work because Python's ord() and Perl's ord return the Unicode scalar value, not a UTF-8 byte.
printf with %d or %x and the leading-quote trick (printf "%d " "'A") prints the value of the first byte in the current locale. This breaks the moment a character needs more than one UTF-8 byte, which is why a shell pipeline often looks fine for "A" and behaves strangely for "Γ©" in a C.UTF-8 shell. xxd and hexdump -C are byte-level tools; they show the raw UTF-8 sequence (C3 A9 for Γ©) but they do not show the Unicode code point. Conflating bytes with code points is the most common mistake people make when moving from ASCII to mixed scripts. A standalone utility called uni wraps UnicodeData.txt into a small CLI that prints names and properties for any code point, and several distributions expose uniname for similar lookups. These are useful for cross-referencing names but require a separate install.
The practical takeaway is that the command line covers ASCII lookup through man ascii, scalar lookup through Python or Perl one-liners, and byte lookup through xxd, while Unicode-name lookup usually requires another tool. A convenient companion for the UTF-8 byte side of the same work is the workflow described in the Base64 decode on Linux guide, which covers the same shell-driven encoding territory from a different angle.
Browser-based char code lookup
A browser tool such as the Unicode Encoder / Decoder runs entirely on the page; nothing is uploaded, every conversion stays local. It iterates the string by Unicode scalar value rather than by JavaScript UTF-16 code unit, so a supplementary-plane character such as π stays a single token (U+1F600) instead of being split into a surrogate pair. Decode mode accepts the same labels the encoder produces: tokens beginning with U+ or the JavaScript-style \u{...} brace notation, separated by spaces, commas, or line breaks. Hexadecimal is case-insensitive, and every token is checked against the full scalar range before it is turned back into text.
This matters for diagnostic work where the question is character identity rather than byte representation. Pasting "cafΓ©" into the encoder returns U+0063, U+0061, U+0066, U+00E9, and pasting the same labels back into decode mode reconstructs the original string exactly. Pasting "π©βπ»" returns three tokens β U+1F469, U+200D, U+1F4BB β because that emoji is a sequence, not a single code point. The tool also surfaces invisible characters such as the zero-width joiner (U+200D) and the line feed (U+000A), which often explain why pasted text fails an exact comparison or why a cursor jumps unexpectedly. The implementation iterates by Unicode scalar and formats each as uppercase U+ hexadecimal with a four-digit minimum, then validates that every decoded token falls inside U+0000 to U+10FFFF and outside the surrogate interval.
Look up Unicode scalar values in the browser
- Open the Unicode Encoder / Decoder page and confirm that text-to-code-points is the selected direction.
- Paste the exact string you want to inspect, including any invisible characters such as zero-width joiners or non-breaking spaces.
- Convert and read the U+ tokens. Basic characters appear with at least four hexadecimal digits (A becomes U+0041), while supplementary characters keep their full value (π becomes U+1F600 rather than two surrogate halves).
- To work in the other direction, switch to decode mode and enter prefixed tokens such as U+0041 or \u{1F600}, separated by spaces, commas, or line breaks.
- The output text is built only after every token passes scalar-value validation; tokens outside U+0000 through U+10FFFF, and any value in the U+D800 through U+DFFF surrogate interval, are rejected instead of being silently replaced.
Command line vs online at a glance
Neither path is universally better. The choice depends on the surrounding workflow and on how far the lookup has to reach beyond ASCII.
| Use case | Command line | Unicode Encoder / Decoder (browser) |
|---|---|---|
| Printable ASCII reference | man ascii covers 32β126 in one page | Paste any character, get its U+ label |
| Single-character scalar | python3 -c "print(hex(ord(c)))" | One paste, one token out |
| Supplementary-plane emoji | Needs Python or Perl one-liner | Native, single token per emoji |
| Joined / ZWJ emoji | Manual split in code | Revealed as an explicit sequence |
| UTF-8 byte view | xxd, hexdump | Not the goal here β use a byte converter |
| Invisible-char inspection | Byte-level only on bare shells | U+200D and U+000A shown explicitly |
| Reuse inside scripts | Trivial, runs in any shell | Manual paste, then copy out |
| Works offline | Only if tools are preinstalled | Runs in any modern browser tab |
Scalar values, UTF-16 units, and UTF-8 bytes
The diagnostic that matters for most engineers is which abstract characters a string contains, not which bytes travel through a particular protocol. The Γ© character is the scalar U+00E9, but in UTF-8 it becomes the two-byte sequence C3 A9, and in JavaScript's internal UTF-16 representation it is still a single code unit because U+00E9 is well below the supplementary-plane cutoff. As a single worked example, take U+00E9: the hexadecimal digits 0, 0, E, 9 combine as 0Γ4096 + 0Γ256 + 14Γ16 + 9 = 233 in decimal, and the UTF-8 two-byte form packs those eleven bits as 11000011 10101001, which is C3 A9. The scalar is what the Unicode Encoder / Decoder reports; the bytes are what the UTF-8 converter reports, and the two answers are both correct at their own level.
The interesting case is a supplementary-plane character such as π (U+1F600). Its scalar value is 128512, well above U+FFFF, so UTF-16 represents it as a surrogate pair (D83D, DE00) and UTF-8 writes it as four bytes (F0 9F 98 80). Neither encoding is the scalar. The Unicode Encoder / Decoder reports the scalar and rejects anything in the surrogate interval on the way back in, which avoids the self-consistency trap where one agent's wrong surrogate scheme round-trips with itself.
Normalization is also out of scope. The precomposed Γ© (U+00E9) and the decomposed sequence e plus combining acute accent (U+0065 U+0301) render identically but remain different sequences in the tool's output. That exactness is precisely the point when you are trying to diagnose why a filename, search hit, or identifier comparison fails. When the question changes from "which character" to "which bytes," the right tool is the UTF-8 converter rather than scalar lookup, and the underlying standard is documented in the Unicode Code Charts.
What this tool does not show
The Unicode Encoder / Decoder is intentionally narrow. It does not look up official character names, scripts, confusable status, or language meaning, and it does not segment grapheme clusters. The π©βπ» example above is presented as three scalars, even though a single grapheme cluster is what a person reads on screen. For names and properties, the Unicode Code Charts remain the canonical reference; for the JavaScript-style \u{...} brace notation that decode mode accepts, the authoritative behavior is defined by ECMAScript String.fromCodePoint. A useful companion for syntax examples is the U+XXXX and \u{} cheat sheet, which drills into the same notation this tool accepts.