Free Character Map Online

Character Map: Look Up Any Unicode Character by Code Point

A character map exists for the moment when you need one specific symbol — an em dash, a section mark, a Greek letter, an arrow — that isn't sitting on your physical keyboard anywhere. This page offers two complementary ways to find it: a browsable grid organized around a handful of common code-point ranges, where you click through blocks of characters and copy whichever one you land on, and — through this site's API — a direct lookup that takes a single code point or character and returns its full identity: name, hexadecimal and decimal code, HTML entity codes, raw UTF-8 bytes, and an approximate category.

The two aren't identical in what they show. The on-page grid is built for visually scanning a block of characters and grabbing the one you recognize by sight; it displays each character alongside its hex code but doesn't attempt to look up or display a name for anything in the grid. The API lookup goes further, resolving an actual name for a code point where one is available in this tool's curated reference data — useful when you have a code point or a pasted character and need to know exactly what it's called, not just what it looks like.

How to Browse and Copy Characters on This Page

1. The grid opens by default showing the standard printable ASCII range — code points 33 through 126, roughly from "!" up through "~" — covering the punctuation and symbols most commonly needed first.
2. Click one of the seven category buttons above the grid — Latin Letters, Digits, Math Symbols, Arrows, Box Drawing, Currency, or Emoji — to jump straight to that block of code points instead of scrolling manually.
3. Type into the search field to narrow the characters currently on screen — it matches either the literal character itself or a piece of its hex code, searched within whichever range or category is currently loaded rather than across the entire grid history.
4. Hover over any character in the grid to see a tooltip listing its code point in both hex ("U+" notation) and plain decimal form.
5. Click a character to copy it directly to your clipboard — a brief green highlight confirms the copy went through.
6. Each range loaded through a category button is capped at a manageable size so the grid stays quick to scan and scroll, rather than trying to render an enormous block of code points in one view.

Why People Look Up Unicode Characters

• Finding a symbol that isn't on a standard keyboard. An em dash, a degree sign, a section mark, or a fraction character all exist in Unicode but have no dedicated key on most keyboards — browsing or looking one up directly is faster than hunting for an obscure key combination.
• Identifying a mystery character pasted from somewhere else. A document or webpage sometimes contains a character that looks unfamiliar or renders oddly — looking up its code point clears up exactly what it is and why it might be behaving differently than expected.
• Getting the right HTML entity for a web page. Writing raw HTML sometimes calls for an entity code rather than a literal pasted character, particularly for symbols that don't type reliably across different editors and encodings.
• Debugging a text-encoding problem. When a character displays as a garbled symbol or a placeholder box, checking its actual code point and category is often the fastest way to understand what went wrong during a copy, save, or transfer between systems.
• Typography and document design work. Choosing the correct dash, quotation mark, or space character for a specific typographic purpose — rather than whatever a word processor auto-substitutes — depends on knowing exactly which code point is being used.
• Programming and data work involving specific characters. Writing a regular expression, a validation rule, or a parser that needs to reference an exact code point benefits from a quick, reliable way to confirm hex and decimal values rather than guessing.

What a Character Lookup Actually Returns

The API's lookup accepts a single code point in several common formats, so you don't need to already know the exact syntax it expects:

Input format	Example	Interpreted as
"U+" notation	U+2764	Hexadecimal code point 2764
"0x" notation	0x2764	Hexadecimal code point 2764
Bare hex (contains a letter a-f)	2fa4	Hexadecimal code point 2FA4
Bare all-digit string	10084	Decimal code point 10084
A single literal character	❤	That exact character's own code point

A single typed character is always read literally rather than interpreted as a number — typing the digit "5," for instance, looks up the actual character U+0035 (the digit-five glyph itself), not the number five as a decimal code point, since there'd be no reliable way to tell the two apart otherwise. A bare all-decimal string longer than one character, on the other hand, is read as a decimal code point, matching how a plain number is conventionally interpreted when there's no hex prefix attached to it.

The response includes the character itself, its code point formatted as "U+XXXX," the hex and decimal values separately, both decimal and hexadecimal HTML entity codes ready to paste into markup, the character's raw UTF-8 byte sequence, and an approximate category label such as "Currency Symbol," "Arrow," or "Greek Letter" based on which Unicode block the code point falls into. The name field is where this tool is deliberately conservative: it's populated only from a curated reference set — common arrows, currency symbols, punctuation, math symbols, and Greek letters, plus the names in this site's emoji dataset — and comes back as null, honestly, for any valid character outside that curated set rather than guessing at or fabricating a name it doesn't actually have on file. A plain letter like "A" or an uncommon symbol from a less common Unicode block, for example, will return its hex, decimal, entity codes, and category correctly, but a null name rather than an invented one.

A Few Character-Lookup Realities

Worth knowing up front: the on-page grid and the API lookup aren't the same tool wearing two different outfits — they genuinely do different jobs. The grid is a range browser; it shows you what a block of characters looks like and lets you copy by sight, but it has no name-lookup logic built into the page itself. The API is a targeted lookup; it needs a specific code point or character to work with rather than a range to browse, and it can tell you a name only when that particular code point happens to be in the curated reference set described above. Its category classification is also an approximation based on Unicode block ranges rather than a complete, authoritative Unicode character database — it's accurate enough to answer "roughly what kind of character is this" at a glance, but it isn't pulling from the full official Unicode Character Database with every character's officially assigned name and category.

Why the UTF-8 Bytes Matter, Even If You Never Look at Them

Alongside the hex, decimal, and entity values, the API's lookup also returns a character's raw UTF-8 byte sequence — the actual bytes a computer stores and transmits for that character, as opposed to the more human-friendly code point number. Most people looking up a character never need this field, but it matters in a specific class of problem: diagnosing why a character that should display correctly instead shows up as a run of garbled symbols, often something like a sequence of accented question marks, after being saved, uploaded, or transferred between two systems that disagree about text encoding. That garbling is almost always a byte-level mismatch — a file or database column expecting one encoding while the actual bytes were written in another — and having the correct UTF-8 byte sequence for a known character on hand is a genuinely useful reference point when tracing exactly where an encoding conversion went wrong in a pipeline.

The hex and decimal fields, by contrast, are the ones almost every lookup actually needs day to day — hex because "U+" notation and most programming languages' Unicode escape syntax are hex-based, decimal because some contexts, like certain HTML numeric character references, expect a plain base-10 number instead. Having both available side by side, along with the ready-to-paste HTML entity forms, removes the need to convert between number bases by hand for whichever format a given task happens to call for.

Manual Character Lookup vs. Using This Tool

• Your operating system's built-in character viewer. Windows' Character Map and macOS's Character Viewer both let you browse and insert Unicode characters directly, and are worth knowing about — but neither gives you a code point's hex, decimal, and HTML entity values side by side in one glance the way a dedicated lookup does.
• Keyboard alt-codes and shortcuts. Memorizing a handful of alt-codes for frequently used symbols is efficient once learned, but doesn't scale to the much larger set of characters someone might need only occasionally.
• The official Unicode Consortium reference tables. Authoritative and complete, but formatted for technical reference rather than a quick "what is this character" lookup, and considerably more involved to search through than typing one code point into a form.
• This tool's API. For a script, a content-management workflow, or any automated process that needs to resolve code points programmatically instead of through a browser tab, the same lookup logic — including the curated name resolution and category classification — runs as a metered API call that accepts a code point and returns its full breakdown as JSON; the API documentation spells out exactly what to send and what each call costs.

Does the on-page grid show a name for each character?

No — the browsable grid on this page shows the character itself alongside its hex code and decimal value, but it doesn't display a resolved name. Name lookup is handled by the API endpoint instead, and only for code points in its curated reference set.

Why does a character I looked up come back with a "null" name?

The name field is populated only from a curated set of common arrows, currency symbols, punctuation, math symbols, Greek letters, and the emoji in this site's dataset. A valid character outside that specific set — most plain letters, for instance — returns every other field correctly but a null name, rather than a guessed or fabricated one.

Can I search for a character by typing its name instead of a code point?

Not on the API's lookup endpoint — it expects a code point or a single literal character as its query, not a name search. For finding an emoji specifically by a descriptive word, the separate emoji-search tool handles name-and-keyword matching instead.

What's the difference between the hex and decimal values shown?

They're the same code point expressed in two different number bases — hexadecimal (base 16, as used in the "U+" notation) and decimal (base 10). Both describe the identical character; which one you need depends on what a particular programming language, CSS rule, or document format expects.

Does this tool cover the entire Unicode standard?

The lookup accepts any valid Unicode code point across the full 0 to 10FFFF range (excluding the surrogate range reserved for internal encoding use), so a code point itself will resolve for essentially anything valid. The name and category fields, however, draw from a curated reference set rather than the complete official Unicode character database, so those two fields are more limited than the code-point coverage itself.

What's the UTF-8 byte sequence useful for?

It's mainly a diagnostic tool for text-encoding problems — comparing a character's known-correct UTF-8 bytes against what actually got stored or transmitted somewhere is a reliable way to pin down where an encoding mismatch crept into a file, database, or data pipeline.

Related Everyday Tools

If what you're actually hunting for is an emoji rather than a punctuation mark or symbol, the emoji search tool matches by name and keyword instead of code point, which is usually the faster path for that specific case. Once you've copied a character into place, the text case converter and the character counter both handle common next steps — reformatting the surrounding text or confirming exactly how many characters a finished piece of copy adds up to.