On macOS, char code lookup means mapping every visible character to its Unicode scalar value — and a browser-based Unicode encoder can list each U+ value for any text you paste, with no install required. The built-in Character Viewer shows the code point for one selected glyph, and the Unicode Hex Input keyboard only inserts characters from hex codes, yet neither quickly exposes the full scalar sequence behind a multi-code-point emoji, a precomposed accent, or a pasted string full of invisible characters. A dedicated Unicode Encoder / Decoder iterates the string as Unicode code points rather than JavaScript UTF-16 code units, so supplementary emoji like 😀 stay together as U+1F600 instead of splitting into a high-low surrogate pair. The same tool accepts prefixed U+XXXX or JavaScript-style \u{...} tokens and rebuilds the original text once every token passes scalar validation. Everything runs locally in the browser, the input is capped at 100,000 code points to keep rendering responsive, and surrogates U+D800 through U+DFFF are rejected outright because they identify UTF-16 code units, not standalone characters. That combination of behavior is what makes a browser path genuinely useful for char code work on a Mac.
macOS Char Code Tools at a Glance
macOS already ships with two native paths to a code point. The Character Viewer (Edit → Emoji & Symbols) lists the four-digit hex value for a single selected glyph, which is fine for one-off lookups. The Unicode Hex Input input source only goes in the other direction: holding Option while typing four hex digits inserts the character. For diagnostics — "why does this string not compare equal?" or "what exactly did I copy from that PDF?" — neither is fast, and neither prints a multi-code-point emoji, a normalization pair, or a hidden zero-width joiner as a readable sequence. The browser tool plugs that gap without adding anything to the system.
| Method on Mac | Direction | Supplementary-plane handling | Reads U+XXXX or \u{} tokens | Runs offline |
|---|---|---|---|---|
| Character Viewer | Character → code point | Shows the scalar hex for one glyph | No | Yes (system app) |
| Unicode Hex Input keyboard | Hex code → character | Types supplementary values when five hex digits are given | No | Yes (system input) |
| Browser Unicode Encoder / Decoder | Both directions | Keeps supplementary scalars as one U+ value | Accepts U+XXXX and \u{...} | Yes (local browser page) |
For a quick one-character spot check on a Mac, the Character Viewer is enough. For batch inspection or for turning a documentation snippet back into text, the browser tool earns its place.
Looking Up Char Codes on Mac in the Browser
Any recent macOS browser will run the encoder locally — no Terminal, no Homebrew, no permission prompts. Safari, Chrome, Firefox, or Arc all work equally well, and the page never uploads input, so pasting customer data, log excerpts, or filenames is safe. The encode direction takes whatever is on the clipboard, including invisible whitespace and zero-width joiners, and returns a clean list that can be copied straight back out.
- Open Safari or another modern browser and load the Unicode Encoder / Decoder.
- Pick the encode direction so the input area expects raw text rather than U+ tokens.
- Copy the string to inspect from any macOS app — a code editor, Mail, a Terminal transcript, or a Finder filename — and paste it verbatim into the input box.
- Trigger the conversion so each Unicode scalar renders as an uppercase U+XXXX token. Supplementary-plane characters come back with five or six hex digits, such as U+1F600.
- Copy the resulting token list back to the clipboard, or read it on screen to spot invisible characters, stray control bytes, or surrogate halves that should not be present at all.
If the same Mac user later needs to reconstruct text from a documentation snippet, a hex dump, or a code review comment, the decode direction handles prefixed U+XXXX and JavaScript-style \u{...} tokens in a single pass with the same validation rules.
Reading a U+ Sequence: What the Values Tell You
A U+ sequence is a diagnostic snapshot of a string at the Unicode scalar level. Basic Latin letters come back as four-digit values such as U+0041 for "A". Accented letters expose precomposed forms versus decomposed combinations — the same visible é can be U+00E9 or the pair U+0065 U+0301, depending on the source. CJK characters live in the higher planes and often need five digits, while supplementary emoji land in the five- or six-digit range.
| Input character | Output U+ values (typical) | Notes |
|---|---|---|
| A | U+0041 | Basic Latin, four-digit minimum |
| é (precomposed) | U+00E9 | One scalar value |
| é (decomposed) | U+0065 U+0301 | Two scalars, visually identical to the precomposed form |
| newline | U+000A | Control character, included explicitly |
| 😀 | U+1F600 | Supplementary scalar value, kept as one token |
| 👩💻 | U+1F469 U+200D U+1F4BB | Woman + ZWJ + laptop, three scalars per the Unicode Standard |
Because the encoder iterates by scalar value, 😀 is a single token rather than the artificial UTF-16 split U+D83D U+DE00. That distinction is the reason the tool is built on String.fromCodePoint semantics rather than legacy char-code-at behavior. Surrogate halves U+D800 through U+DFFF never appear, because the same exclusion range applies to any token the encoder would otherwise produce. Spotting tokens like U+200D in a string is often the missing clue when a copy-paste comparison keeps failing on a Mac: a zero-width joiner was sitting in one of the two strings, invisible to the eye but present in the bytes.
Decoding U+XXXX and \u{} Tokens Back Into Text
The other half of the workflow matters when the input is documentation rather than live text. Bug reports, log lines, and source comments often quote characters as U+2014 or \u{2014}, and JavaScript string literals use \u{1F600} for supplementary values. The Unicode Encoder / Decoder accepts both notations and rebuilds the original text once every token passes scalar validation. Hexadecimal digits are case-insensitive, tokens can sit on the same line separated by spaces or commas, and line breaks serve as delimiters too. Tokens that fall outside U+0000 through U+10FFFF, or inside the surrogate range, are rejected with no fallback character inserted — a useful guarantee when a malformed snippet would otherwise become a row of replacement glyphs on a Mac terminal.
For a fuller grammar of these notations, the Char Code Lookup Cheat Sheet: U+XXXX and \u{} Syntax walks through the prefix rules and the brace form \u{1F600} used for supplementary values. The cheat sheet and the main encoder share the same scalar-validation logic, so what decode mode accepts on the main tool is exactly what the cheat sheet predicts.
When a Code Point Still Isn't the Whole Story
Char code lookup answers one narrow question: which abstract characters does this string contain. It does not answer the byte-level question a protocol or file format will eventually ask. U+00E9 identifies é; the UTF-8 representation of that same character is the two bytes C3 A9, and a UTF-16 representation is the two bytes 00 E9. If the downstream system speaks bytes rather than code points, switch over to the UTF-8 Encoder / Decoder and run the same input through that pipeline instead.
Normalization is the other common surprise. Precomposed U+00E9 and decomposed U+0065 U+0301 render identically but compare as different sequences; the tool deliberately does not normalize, so the output stays byte-exact against the pasted source. That exactness is exactly what helps diagnose a search, identifier, filename, or comparison problem on a Mac: the answer reveals what is actually in the string rather than what ought to be.
For daily diagnostics, the practical ladder is: paste into the browser tool to learn the scalar sequence, scan for any ZWJ or control character hiding in the string, copy the U+ list into a ticket or test file, and reach for a byte-level converter only when the next layer down matters.