A char code lookup on iPhone means finding the Unicode code point — the U+XXXX label that uniquely identifies a character — for any symbol, letter, or emoji you encounter on the device. The iPhone keyboard shows visible glyphs and long-press variants, but it never displays the underlying U+ value, so users who need to know whether a pasted symbol is U+00E9 (é) or the decomposed pair U+0065 U+0301 (e + combining acute) have no built-in path. The practical solution is a browser-based Unicode Encoder / Decoder that runs locally in Safari, accepts any character you paste or type, and returns the exact sequence of scalar values your iPhone clipboard actually contained. Because the conversion happens in the browser tab itself, nothing is uploaded, and the same workflow handles supplementary emoji, accented Latin letters, CJK characters, and the invisible code points such as U+200D that often hide inside flag, family, and profession emoji.
Why iOS Does Not Show Code Points Natively
Every character your iPhone displays is backed by a number from the Unicode table, but the iOS software layer never surfaces that number. The on-screen keyboard offers long-press menus for accented letters, alternate punctuation, and emoji variant selectors, yet every entry in those menus is still a character, not a value. There is no iOS field, dialog, or share-sheet option that reports U+0041 for an "A" or U+1F600 for a grinning face. The macOS Character Viewer includes a "Keystroke" field that prints the code point label, but the equivalent on iOS stops at the glyph and its name.
This matters in real troubleshooting. A filename fails to match because one copy was saved as U+00E9 and another as U+0065 U+0301 even though both render identically. A search misses an emoji because a zero-width joiner (U+200D) sits between two code points the indexer treats as separate keys. A copied symbol moves the cursor one position instead of zero because U+200B or U+FEFF came along for the ride. None of those bugs are visible at the iPhone keyboard level, and they cannot be diagnosed without converting the on-screen character back into its scalar values.
How to Look Up a Char Code on iPhone
The browser workflow below works on any iPhone running iOS 13 or later and uses only Safari and the system clipboard.
- Copy the character you want to inspect. Long-press a character in Notes, Mail, Safari, or any app and choose Copy. For an emoji on the keyboard, switch to the emoji keyboard, find the symbol, then tap and hold the prediction bar to copy.
- Open Safari and navigate to the Unicode Encoder / Decoder tool.
- Make sure the mode is set to encode text to code points. The first input field accepts the exact Unicode string, including invisible characters such as zero-width spaces and joiners that often hide inside copied text.
- Tap inside the input field, then tap the on-screen Paste button that floats above the keyboard. The character now sits in the field exactly as your clipboard stored it.
- Tap the Convert button. The output panel populates with one U+ token per scalar value in your input. Supplementary-plane characters stay as a single U+XXXXXX value rather than being split into two surrogate halves.
- Read the tokens in order, or tap and hold inside the output to select and copy the entire U+ sequence into a new Note, email, or messaging thread for later reference.
Because the conversion runs in the browser tab, the iPhone never sends the character to a remote server. The same path also works in Chrome for iOS, Firefox for iOS, and any other browser that supports standard JavaScript string handling.
Reading a U+ Sequence From a Real Emoji
The fastest way to see why a single visible symbol can hide several code points is to encode the emoji 👩💻 (woman technologist) on the iPhone. Paste it into the encode field, convert, and the output panel shows three tokens in this exact order:
- U+1F469 — WOMAN, the base character
- U+200D — ZERO WIDTH JOINER, the invisible glue
- U+1F4BB — PERSONAL COMPUTER, the modifier that turns "woman" into "woman technologist"
That same three-token sequence is what every iPhone paste, every iCloud sync, and every text-message send actually carries. The iPhone renders the three scalar values as a single colorful image because the system font applies the Unicode emoji-presentation rules, but the underlying buffer holds three separate numbers. The same shape appears for family emoji, most profession emoji, and many flag combinations, so this example doubles as a template for any joined sequence you need to inspect on the device.
For a single-codepoint example, the basic Latin letter A encodes as U+0041 and the grinning face emoji 😀 encodes as U+1F600. The encoder pads every basic character to at least four hexadecimal digits, so a single ASCII letter always reads as U+0041 rather than U+41.
Going the Other Way: Decoding U+ Tokens on iPhone
The same tool also rebuilds text from documented code points. Switch to decode mode and paste a sequence such as U+1F469 U+200D U+1F4BB separated by spaces, commas, or line breaks. The decoder validates each token, rejects anything outside the valid scalar range U+0000 through U+10FFFF, and refuses surrogate values in the excluded interval U+D800 through U+DFFF that are reserved for UTF-16 pairs. Hexadecimal digits are case-insensitive, so U+1f600 and U+1F600 are both accepted.
The decoder also understands the JavaScript-style \u{...} notation used in source code and console output. A log line that prints \u{1F600} decodes to the grinning face emoji, and a configuration file containing \u00E9 decodes to é. The brace form is required for supplementary values, because the four-digit \uXXXX form in JavaScript can only address the basic multilingual plane.
For a compact reference of both token formats, the Char Code Lookup Cheat Sheet for U+XXXX and \u{} syntax summarises which prefix belongs to which system and which separator each consumer expects.
Code Points Versus UTF-8 Bytes on iPhone
A common confusion when working with characters on iPhone is treating the Unicode code point and the UTF-8 byte sequence as the same number. They are not. The character é has the code point U+00E9, a single abstract value, but its UTF-8 representation is the two bytes C3 A9. Both forms are correct, and the right choice depends on what the receiving system expects.
| What you have | What you need | Where to look |
|---|---|---|
| Visible character on iPhone | U+XXXX code point label | Unicode Encoder / Decoder, encode mode |
| Code point label from documentation | Visible character | Unicode Encoder / Decoder, decode mode |
| Text that must travel as bytes | UTF-8 byte sequence | UTF-8 Encoder / Decoder |
| Data that must travel as percent-encoded ASCII | URL-encoded string | URL Decoder / percent-encode tool |
If a network protocol, file format, or API contract specifies bytes, the code point label is one level of abstraction too high, and the UTF-8 view is what matters. If the question is which abstract characters a string contains, the code point view is the ground truth.
Limits and What the Tool Will Not Tell You on iPhone
Three boundaries matter for any iPhone workflow. First, the encoder caps input at 100,000 code points to keep rendering and copying responsive on the device, so very long pasted logs should be split before encoding. Second, the tool deliberately does not normalize. A precomposed é and a decomposed e + combining acute both pass through as written, which is the correct behavior for diagnosing why two strings do not match. Third, the scalar sequence is not the same as a grapheme cluster. The 👩💻 example outputs three code points, and the tool does not claim those three tokens form a single user-perceived cluster, nor does it segment the input the way a full Unicode segmentation algorithm would.
The tool also does not look up character names, scripts, confusable status, or language meaning, and it does not validate whether a sequence forms a recommended emoji. Those are separate Unicode properties beyond reversible scalar conversion. The scalar-level reasoning that drives JavaScript's String.fromCodePoint, documented in the ECMAScript specification, is the same model the encoder uses: iterate by code point, format as U+ hexadecimal, and never split supplementary characters into surrogate halves.
For most iPhone users, those limits are exactly the right shape. The job is to convert what is on the screen into the U+ values the rest of the computing world uses to refer to it, and to do it on the device already in the hand. A browser tab in Safari, a paste from the clipboard, and a single convert tap is the shortest path between those two views.
For a deeper look, see ASCII Code Converter on iPhone: Open It in Safari.