Encoding Calculator

Text encoding is the process of converting human-readable characters into a sequence of numbers or symbols that computers can store, transmit, and interpret. Every letter, digit, punctuation mark, and emoji you type must be translated into binary data before a computer can work with it. The encoding calculator on this page lets you instantly see how any text string looks across ten different encoding formats simultaneously — from raw binary bytes to Base64 to URL-percent encoding.

At its core, every character encoding system maintains a character map: a lookup table that assigns a unique numerical value (called a code point) to each character. The oldest and most familiar encoding system is ASCII (American Standard Code for Information Interchange), which assigns values 0–127 to the 128 characters needed for English text and common punctuation. ASCII works perfectly for "Hello" but has no way to represent "こんにちは" or "مرحبا".

The explosion of global internet use in the 1990s made ASCII's limitations untenable, and the Unicode standard emerged as the universal solution. Unicode defines a unique code point for every character in every writing system on Earth — more than 149,000 characters as of Unicode 15.1. But Unicode is a character set, not an encoding; you still need an encoding scheme to store Unicode code points as bytes. That is where UTF-8, UTF-16, and UTF-32 come in.

Understanding encoding is essential in software development, data engineering, web development, and security. Encoding bugs are among the most common sources of "mojibake" (garbled text), SQL injection vulnerabilities, and cross-site scripting (XSS) attacks. When you properly encode user input as HTML entities before inserting it into a web page, for instance, you prevent malicious scripts from running. When you URL-encode a search query before appending it to a URL, you prevent the query from breaking the URL structure.

This free encoding calculator handles UTF-8 hex, UTF-8 binary, UTF-16 hex, Unicode code points (U+ notation), Base64, URL encoding, HTML entities, raw hex string, octal, and ROT13 — giving developers, students, and security professionals a quick reference for any text input.

Each encoding format on this calculator serves a different purpose. Understanding which format to use — and why — is a key skill for anyone working with text, data serialization, web APIs, or security.

UTF-8 (Hex and Binary)

UTF-8 is the dominant encoding standard on the web, used by over 98% of websites. It is a variable-width encoding: ASCII characters (U+0000 to U+007F) are stored as a single byte, characters in common scripts like Latin, Greek, Arabic, and Cyrillic use two bytes, East Asian characters typically use three bytes, and supplementary characters (including most emoji) use four bytes. This variable-width design makes UTF-8 backward-compatible with ASCII while still supporting the full Unicode range. The calculator shows UTF-8 output in both hexadecimal (e.g., 48 65 6C 6C 6F) and binary (e.g., 01001000 01100101...) representations.

UTF-16 (Hex)

UTF-16 uses 16-bit (two-byte) code units. Characters in the Basic Multilingual Plane (U+0000 to U+FFFF) use a single 16-bit code unit, while supplementary characters use two code units called a surrogate pair. JavaScript's internal string representation uses UTF-16, which is why charCodeAt() returns 16-bit values. This calculator uses charCodeAt() to generate the UTF-16 hex output for each character position.

Unicode Code Points (U+ Notation)

A Unicode code point is the abstract numerical identifier assigned to each character in the Unicode standard, written with the U+ prefix. For example, the letter "A" is U+0041, the euro sign "€" is U+20AC, and the face with tears of joy emoji is U+1F602. Code points are the canonical identity of a character, independent of any byte encoding. This calculator uses JavaScript's codePointAt() method, which correctly handles supplementary characters (code points above U+FFFF) that UTF-16 represents as surrogate pairs.

Base64

Base64 encodes arbitrary binary data as a string of 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). It is widely used for embedding images, fonts, and other binary data in HTML/CSS, transmitting binary data in JSON payloads, encoding email attachments (MIME), and storing credentials in HTTP Basic Authentication headers. Base64 increases data size by approximately 33%. The calculator uses btoa(unescape(encodeURIComponent(input))) to correctly handle multi-byte characters.

URL Encoding (Percent Encoding)

URL encoding replaces characters that are not safe in a URL with a percent sign followed by two hexadecimal digits representing the UTF-8 byte value of that character. For example, a space becomes %20 and an ampersand becomes %26. This is essential whenever user-supplied data is included in a URL query string, path segment, or form submission. The calculator uses JavaScript's encodeURIComponent(), which encodes all characters except letters, digits, and the characters - _ . ! ~ * ' ( ).

HTML Entities

HTML entity encoding replaces characters that have special meaning in HTML — specifically < > & " ' — and any character with a code point above 127, with numeric character references in the form &#charCode;. This is a critical security measure: properly HTML-encoding all user-supplied text before rendering it in a page prevents cross-site scripting (XSS) attacks. The calculator applies &#charCode; notation to all non-ASCII characters and the five HTML special characters.

Hex String and Octal

The hex string format concatenates the two-digit hexadecimal representation of each character's byte value (using charCodeAt()) into a continuous string — a common format in debugging output, wire protocol inspection, and cryptographic operations. Octal converts each character's code point to base-8, a format occasionally used in Unix file permissions contexts and older programming environments.

ROT13

ROT13 is a simple letter-substitution cipher that replaces each letter with the letter 13 positions ahead in the alphabet. Because there are 26 letters, applying ROT13 twice returns the original text — it is its own inverse. ROT13 is not a security mechanism but is used to obscure spoilers, puzzle answers, and mildly offensive content in informal contexts. The calculator applies ROT13 to alphabetic characters and leaves all other characters unchanged.

The encoding calculator performs all conversions entirely in the browser using the Web APIs and JavaScript built-in methods listed below. No data is sent to any server. Each conversion happens instantaneously inside a useMemo hook that re-runs whenever you change the input text.

Here is a summary of the conversion method used for each encoding type:

The byte count shown at the top of the calculator reflects the length of the UTF-8 encoded byte array, not the JavaScript string length. For ASCII-only text these are equal, but for text containing multi-byte characters (accented letters, CJK ideographs, emoji) the byte count will exceed the character count.

UTF-8's variable-width encoding scheme is elegant and systematic. The number of bytes used to represent a code point depends on the code point's range, following a well-defined set of bit patterns. Understanding these patterns helps you interpret raw hex dumps and diagnose encoding errors in networked systems.

The leading bits of each byte serve as a self-synchronizing marker. A byte starting with 0 is a complete single-byte ASCII character. A byte starting with 110 introduces a two-byte sequence. A byte starting with 1110 introduces a three-byte sequence. Bytes starting with 10 are continuation bytes. This design allows a UTF-8 decoder to resynchronize after data corruption — it simply skips bytes until it finds one that does not start with 10.

This self-synchronizing property, combined with ASCII backward-compatibility, is why UTF-8 became the dominant encoding for the web, most file systems, and network protocols. When you use this encoding calculator and notice that a simple English word like "Hello" produces exactly as many UTF-8 bytes as characters, but a word like "café" produces five bytes for four characters, that is UTF-8's variable-width encoding at work.

Choosing the correct encoding context is not just a technicality — it is a security requirement. The most common web vulnerabilities, including Cross-Site Scripting (XSS) and SQL Injection, can often be traced to improper or missing encoding. Understanding when and how to apply each encoding format is a foundational skill for web developers and security engineers.

HTML Entity Encoding to Prevent XSS

When user-supplied text is rendered inside an HTML document, every character that has special meaning in HTML must be encoded as an HTML entity. The critical five are: < (less-than, starts tags), > (greater-than, ends tags), & (ampersand, starts entities), " (double quote, inside attribute values), and ' (single quote, inside attribute values). Failing to encode even one of these allows an attacker to inject HTML or JavaScript that runs in the victim's browser context.

URL Encoding in Query Strings and Form Data

Query string values must be percent-encoded before being appended to a URL. Without encoding, a value containing & would split the query string, a value containing = would break key-value parsing, and a value containing # would truncate the URL at the fragment identifier. Use encodeURIComponent() for individual query parameter values and encodeURI() for an entire URL (which preserves the structural characters like /, ?, and &).

Base64 in HTTP and APIs

Base64 is used in HTTP Basic Authentication headers (Authorization: Basic base64(username:password)), data URIs for embedding images directly in CSS or HTML, JSON Web Tokens (JWTs use Base64URL — a URL-safe variant that replaces + with - and / with _), and MIME email attachments. Note that Base64 is encoding, not encryption — it provides no confidentiality and should never be used to protect sensitive data.

UTF-8 as the Default Web Encoding

Always declare <meta charset="UTF-8"> in HTML documents and ensure your server sends the response header Content-Type: text/html; charset=UTF-8. A mismatch between the declared encoding and the actual byte encoding of the file is the most common cause of mojibake — the garbled box-characters and question marks that appear when a browser interprets UTF-8 bytes as ISO-8859-1 or Windows-1252.

Encoding Conversion in Database Operations

Many database collation issues arise from encoding mismatches between the application layer (typically UTF-8), the database connection (which must also declare UTF-8), and the table/column collation. In MySQL, utf8mb4 (not the incorrectly named utf8, which only supports three-byte sequences) is required to store emoji and other four-byte Unicode characters. Always verify encoding consistency across all three layers.

The encoding calculator is designed to be instant and frictionless. You type or paste text into the input area and all ten encoding formats update in real time — there is no submit button to click. Here is a guide to each feature on the page.

1. Input Text Area: Type or paste any text — plain English, Unicode characters, emoji, code snippets, or any mix. The calculator processes all Unicode text correctly, including multi-byte characters and emoji.
2. Character Count: The top-left badge shows the number of JavaScript string positions. For ASCII text this equals the number of characters, but surrogate pairs (emoji and supplementary characters) occupy two string positions each.
3. Code Point Count: The center badge shows the number of actual Unicode code points, using the for...of iterator which correctly groups surrogate pairs. This is the "true" character count for most purposes.
4. UTF-8 Size: The top-right badge shows the total number of bytes required to store the text in UTF-8 encoding. For ASCII-only text this equals the character count; for text with emoji or non-Latin scripts it will be larger.
5. Click to Copy: Each encoding row is clickable. Clicking any row copies that encoding result to your clipboard. The row briefly shows "Copied!" to confirm the action.
6. Clear Button: Empties the input field immediately.
7. Sample Text Button: Loads "Hello World! 🌍" — a useful test string that includes both ASCII and a multi-byte emoji, demonstrating how different encodings handle Unicode characters.

A practical workflow is to paste the text you are working with — a form field value, an API response string, a filename — and immediately see how it would look in the encoding required by your current context. If you are debugging a URL parsing issue, check the URL Encoded row. If you are diagnosing an XSS risk, check the HTML Entities row. If you are preparing a Base64 payload for an API call, the Base64 row gives you the ready-to-use string.