I lost an afternoon once to a single character. A user's name contained an accented letter, it looked fine in the database, broke in a PDF export, and showed up as a pair of question marks in a log. The fix was trivial once I could see the actual code point behind the glyph, but getting there meant three different tools and a lot of squinting. That is the friction I built the unicode converter on toolz.dev to remove: paste any text and see exactly what it is made of, in whatever notation the job in front of you wants, and decode any of those notations back to readable text. This is the guide to it and to the character encoding it exposes.
TL;DR: Every character has a Unicode code point, a number written like U+0041 for A. The Toolz unicode converter turns text into that code point plus decimal, hex, HTML entities (A and A), JavaScript escapes (A), and CSS escapes (\41), and decodes any of them back to text. It handles emoji and other astral characters by true code point so they round-trip correctly, shows a per-character table with UTF-8 bytes, and runs entirely client-side so your text never leaves the browser.
What is a Unicode converter?
A Unicode converter translates between the text you read and the numbers a computer stores for it. Every character, from a plain Latin letter to a Chinese ideograph to an emoji, is assigned a code point by the Unicode Standard, and that code point is usually written in the form U+ followed by four to six hexadecimal digits: U+0041 for capital A, U+00E9 for é, U+4E16 for 世, U+1F30D for the earth emoji. The converter reads whatever you type and shows the code point behind each character, then lets you express that same code point in any of the notations different languages and formats expect.
The reason a single code point has so many written forms is that different contexts have different escaping rules. An HTML document uses character references like A in decimal or A in hexadecimal. A JavaScript string uses A, or \u{1F30D} for characters beyond the basic range. A CSS value uses \41 with a trailing space. A spec, a bug report, or a Unicode chart uses the U+ form. They all point to the same character; they just wear different clothes depending on where they live. The tool produces all of them from one input and reverses any of them, so you never have to remember which syntax a given file wants or retype a tricky character by hand.
What is a Unicode code point, and how is it different from UTF-8?
This is the distinction that clears up most encoding confusion, so it is worth being precise. A code point is an abstract number that identifies a character. It says nothing about how that number is stored in memory or sent over a wire. UTF-8 is one specific way of encoding a code point as a sequence of bytes, defined in RFC 3629. The two are related but not the same thing, and mixing them up is the root of a lot of "why is my text garbled" bugs.
Take é, code point U+00E9. As a code point it is a single number, 233 in decimal. In UTF-8 it is stored as two bytes, C3 A9. In UTF-16 it is one 16-bit unit. The character is one thing; its byte representation depends on the encoding. The per-character table in the converter shows both the code point and the UTF-8 bytes side by side, so when you see a name that renders as é instead of é, you can immediately recognise the classic symptom: UTF-8 bytes being read as if they were a single-byte encoding like Latin-1. Seeing the bytes is often the fastest way to diagnose an encoding mismatch.
Here is a small map of one character across the notations the tool produces.
| Notation | Value for é (U+00E9) |
|---|---|
| Code point | U+00E9 |
| Decimal | 233 |
| Hex | 0xE9 |
| HTML decimal entity | é |
| HTML hex entity | é |
| JavaScript escape | é |
| CSS escape | \E9 |
| UTF-8 bytes | C3 A9 |
How do I convert text to Unicode?
Choose Encode, pick the notation you want, and type or paste your text. The unicode converter shows the encoded output immediately and fills in a per-character table with the code point, decimal value, HTML entity, and UTF-8 bytes for each glyph. Copy the output and drop it into your HTML, stylesheet, script, or document.
The four steps are quick. First, select Encode to go from text to notation, or Decode to go the other way. Second, pick the format: code point, decimal, hex, HTML entity, JavaScript escape, or CSS escape, and for decoding there is an auto mode that detects the common forms for you. Third, enter your text and watch it convert. Fourth, copy the result. There is no upload and no account.
Converting into HTML entities is one of the most common uses, and it overlaps with the dedicated html entities tool, which focuses on named entities like & and ©. The html entities guide covers when a named entity is the right choice and when a numeric one is. This converter complements it by giving you the numeric code point view of any character, named or not.
Does it handle emoji correctly?
Yes, and this is where a lot of simpler converters quietly produce broken output. Characters above U+FFFF live in what Unicode calls the supplementary planes, and JavaScript stores each of them internally as two 16-bit code units called a surrogate pair. If a converter naively walks a string one code unit at a time, it splits an emoji into two halves and emits two meaningless escapes that will never reassemble into the original character.
This tool iterates by true code point, so an emoji like the earth (U+1F30D) is treated as one character throughout. Encode it and you get a single clean value: \u{1F30D} in the ES6 JavaScript form, 🌍 as an HTML entity, U+1F30D as a code point. Decode any of those and the original emoji comes back whole. When decoding older-style JavaScript escapes that were written as surrogate pairs, 🌍, the tool combines the halves correctly rather than leaving you with two broken code units. Round-tripping an emoji through the converter gives you back exactly what you started with, which is the baseline test a Unicode tool has to pass and many fail.
How do I decode Unicode escapes back to text?
Switch to Decode, paste the encoded string, and either pick the matching format or leave it on auto. Auto mode recognises U+ notation, \u and \u{} JavaScript escapes, and &# and &#x HTML entities in the same input, so a mixed paste from a log or a config file still decodes. If you know the exact format, selecting it directly is the most reliable option, especially for decimal or plain hex where bare numbers could otherwise be ambiguous.
Decoding is the half of the job you reach for when you are on the receiving end of encoded text: a JSON payload full of \u escapes, an HTML source view riddled with numeric entities, a stack trace that logged a string in escaped form. Rather than hand-decoding character by character, you paste the whole thing and read the plain text back. The converter reconstructs the original characters and, as noted above, correctly rejoins any surrogate pairs it encounters so astral characters survive the trip.
This pairs well with the other decoding tools on the site. Percent-encoded text in a URL is the job of the url encoder, and base64-encoded binary is handled by the base64 converter. They are different encodings for different transports, and knowing which one you are looking at is half the battle. The web developer toolkit guide lays out how these encoding tools fit together in day-to-day work.
When would I actually need CSS or JavaScript escapes?
More often than you would expect, and usually at the exact moment something is not rendering. In CSS, the content property of a ::before or ::after pseudo-element cannot contain arbitrary characters directly in every situation, so you escape them: a right-pointing arrow becomes content: "\2192". The CSS escaping rules, including the trailing space that terminates a hex escape, are defined in the CSS Syntax Module Level 3, and the converter emits exactly that form so you can paste it straight into a stylesheet.
In JavaScript, escapes let you put a character into source code without depending on the file's encoding or on your editor rendering it correctly. © is unambiguous where a literal copyright symbol might get mangled by a tool in the pipeline. For characters beyond the basic plane, the ES6 \u{...} form is cleaner than a surrogate pair, and the converter uses it for astral characters while keeping the four-digit \uXXXX form for characters that fit in it. HTML numeric character references, the &#...; forms, serve the same purpose in markup and are governed by the WHATWG HTML standard. Having all of these generated from one input means you stop guessing at syntax and copy the correct escape every time.
Which notation should I use, and when?
With seven output formats on offer, the practical question is which one a given task wants, and the answer is almost always dictated by where the character is going to live rather than by preference. If you are writing HTML and need a character that is awkward to type or that would otherwise be interpreted as markup, use an HTML entity: — or its hex twin —. If the character is going into a JavaScript string literal, use the \u escape, and reach for the \u{...} form when the character is beyond the basic plane. If it belongs in a CSS value, especially the content property, use the CSS escape with its trailing space. If you are writing a spec, a comment, or a bug report where you want to name the character unambiguously without rendering it, the U+ code point form is the convention everyone recognises.
The decimal and hex outputs are the ones people reach for less often, but they matter when you are talking to a system that speaks in raw numbers: a database column storing code points, a protocol that transmits characters as integers, a lookup against a Unicode data file. Being able to flip a character to its bare decimal or hexadecimal value, and back again, saves a manual base conversion at exactly the moment you are already deep in a debugging session.
There is one rule that cuts across all of them: whatever notation you emit, decode it back and confirm you get the original character before you trust it. Round-tripping is the cheapest correctness check there is, and it catches the two classic mistakes immediately, a mangled surrogate pair for an astral character and an off-by-one in the hex digits. The converter makes that check a single paste in the opposite direction. If a security-sensitive value is involved, the same discipline applies to the percent-encoding handled by the url encoder, where a wrong escape can change what a server actually receives.
Is it safe to convert sensitive text here?
Yes. Every conversion happens in JavaScript inside your browser. Nothing you paste is sent to a server, nothing is logged, and the tool keeps working with your connection switched off once the page has loaded. You can inspect private strings, user data, or the contents of an internal file without any of it leaving your machine.
That property is not incidental, it is the reason to prefer a client-side tool for this kind of work. The text you run through a Unicode converter is often exactly the text you would least want to hand to a third party: a real user's name you are debugging, a snippet of a private dataset, a string from an unreleased feature. A server-side converter, however trustworthy, is one more party in the chain. Doing the work in the browser removes the question. The broader reasoning is in the data privacy online tools guide, and it applies across every encoding tool on toolz.dev, from this one to the base64 encoding guide and beyond.
Frequently asked questions
How do I convert text to Unicode?
Paste your text into the input area with Encode selected and pick a format such as code point or HTML entity. The tool shows the Unicode representation of every character instantly, all inside your browser.
What is a Unicode code point?
A code point is the number Unicode assigns to a character, written like U+0041 for A. It identifies the character independently of how it is stored, which is why the same code point can appear as an HTML entity, a JavaScript escape, or a CSS escape.
What is the difference between a code point and UTF-8?
A code point is the abstract number for a character; UTF-8 is one way of storing that number as one to four bytes. The per-character table shows both, so you can see that U+00E9 for é is stored as the two UTF-8 bytes C3 A9.
Does it handle emoji correctly?
Yes. Emoji live outside the basic range and are stored as surrogate pairs in JavaScript. The converter reads and writes them by true code point, so an emoji like the earth (U+1F30D) round-trips without splitting into two broken halves.
How do I decode Unicode escapes back to text?
Switch to Decode, paste the encoded string, and choose the matching format or use auto to detect it. The tool reconstructs the original characters, correctly combining any surrogate pairs it finds.
When would I need a CSS escape?
CSS escapes let you put a character into a stylesheet value such as the content property. The tool outputs values like \41 with the trailing space CSS uses to end a hex escape, ready to paste into a content property.
Can it convert the same character to several formats at once?
Yes. Choosing a format sets the main output, and the per-character table always shows the code point, decimal value, HTML entity, and UTF-8 bytes for every character, so you can read multiple notations at a glance.
Is it safe to convert sensitive text here?
Yes. All conversion happens in JavaScript inside your browser. Nothing is sent to a server, nothing is logged, and the tool works with your connection disabled.
The unicode converter is free, runs entirely in your browser, and needs no signup. Encode a character into any notation, decode it back, and read the raw bytes behind any glyph. Explore it alongside the ascii table and the rest of the encoding tools on toolz.dev.
