Skip to main content
AllDevToolsHub
🔤

ASCII ↔ Text Converter

100% Local

Convert between text and space‑separated ASCII codes.

ASCII ↔ Text Converter
Mode
Text → ASCII

Two-way conversion

Convert between text and space-separated ASCII codes. All processing runs locally in your browser.

Try:
This tool runs entirely in your browser. Your input is never uploaded, logged, or sent to AllDevToolsHub or anyone else, and it keeps working offline once the page has loaded.

Paste text to see ASCII codes, or paste space-separated numbers to get text back.

Overview

What is ASCII ↔ Text Converter?

Quickly convert text to ASCII code points and back. Great for debugging encoding issues or generating numeric representations. Runs in your browser.
FAQ

Frequently Asked Questions

Reference

Technical Deep Dive

CONVERTERS

ASCII ↔ Text Converter

Quickly convert any text into its ASCII code points and back. Great for debugging encoding issues or generating simple numeric representations. Runs instantly in your browser.

🔁

Two-Way Conversion

Convert in either direction with consistent semantics on the round-trip.

🎯

Type-Faithful

Preserves nulls, numbers, booleans, and structure, no string-soup translation.

📦

Production-Sized

Built to handle real-world payloads, not just textbook examples.

ASCII Codes: The Numeric Identity of Every Character

Computers don't store letters; they store numbers. The letter 'A' is the number 65. The letter 'B' is 66. Space is 32. Tab is 9. Newline is 10. Every character you see on screen or in a file has a numeric identity, and ASCII is the canonical mapping from numbers to characters for English text.

This converter goes both directions: text in, numbers out, or numbers in, text out. The tool is a magnifying glass for character data, useful any time you need to see what a string is actually made of.

Why Look at Code Points?

Sometimes a string lies. Two strings that look identical on screen may differ at the byte level:

  • café with 'é' as a single Unicode code point (233) vs café with 'e' (101) followed by combining acute accent (769), visually identical, structurally different.
  • A regular space (32) vs a non-breaking space (160), both show as whitespace, behave differently.
  • ASCII apostrophe ' (39) vs typographic smart quote ' (8217), both look like apostrophes, only one matches naive string comparison.
  • Tab (9) vs four spaces (32 32 32 32), both visually indent, code treats them differently.

Looking at code points reveals what's actually there. Many bugs come down to "two strings that look the same don't compare equal", and the answer is always in the code points.

The ASCII Map

The 128 ASCII characters in a compact layout:

Range Type Examples
0-31 Control characters 0 = null, 9 = tab, 10 = LF, 13 = CR, 27 = ESC
32 Space (printable but invisible)
33-47 Punctuation ! " # $ % & ' ( ) * + , - . /
48-57 Digits 0 1 2 3 4 5 6 7 8 9
58-64 Punctuation : ; < = > ? @
65-90 Uppercase letters A-Z
91-96 Punctuation [ \ ] ^ _ `
97-122 Lowercase letters a-z
123-126 Punctuation { | } ~
127 DEL (control)

Some patterns to memorize:

  • 'A' is 65, 'a' is 97. Difference of 32 between cases.
  • '0' is 48. The digit char codes are NOT the digit values, converting '5' to numeric 5 requires charCode - 48 or parseInt.
  • Uppercase < lowercase numerically. ASCII sort puts uppercase before lowercase.

These patterns enable code tricks. To uppercase a lowercase letter:

To check if a char is a digit:

Control Characters: The Invisible Half

The first 32 ASCII codes are control characters, non-printing characters that cause behavior. The important ones:

  • 0, NULL. Often a string terminator in C-like languages.
  • 7, BEL. Beeps the terminal (literally, terminals used to have bells).
  • 8, Backspace.
  • 9, Tab.
  • 10, LF (line feed). Unix newline.
  • 13, CR (carriage return). Old Mac newline. Combined with LF for Windows newlines.
  • 27, ESC. Starts ANSI escape sequences for terminal color and cursor control.
  • 127, DEL. Originally for paper tape, punching all 7 holes "deletes" the character.

Modern code rarely deals with most control characters except newlines and tabs. But when debugging string data from old systems, weird control characters appear and code-point output reveals them.

Unicode and Beyond

ASCII covers English. Everything else needs more bits. Unicode assigns code points to characters from every script:

  • 65, A (ASCII).
  • 233, é.
  • 20013, 中 (Chinese "middle").
  • 128512, 😀.

JavaScript's charCodeAt(i) returns 16-bit values. For characters in the Basic Multilingual Plane (0-65535), this is the full code point. For characters above (most emoji, historic scripts), JavaScript uses surrogate pairs: two 16-bit values that together encode one code point.

The 😀 emoji (U+1F600) is JavaScript-internal:

  • charCodeAt(0) = 55357 (high surrogate)
  • charCodeAt(1) = 56832 (low surrogate)

To get the actual code point 128512, use codePointAt(0). The converter resolves these correctly so you see 128512, not two surrogate values.

Real Bugs Diagnosed By Code Points

The smart-quote bug. User pastes text from Word into a form. Validation regex ^[a-zA-Z' ]+$ fails on names like "O'Brien". Why? Word replaced the ASCII apostrophe (39) with a typographic smart quote (8217). Code-point view of the input shows 8217, bug identified.

The invisible character bug. Test data copied from a webpage includes zero-width spaces (8203) hidden in the strings. The string "hello" is actually "hello" + invisible chars, length 5+, breaking byte-exact comparisons. Code-point view: 104 101 108 108 111 8203.

The trailing space bug. Database query returns "value " with a trailing space. Looking at the string, you only see "value". Code-point view: 118 97 108 117 101 32. Trailing 32 = space. Got it.

The wrong-newline bug. File created on Windows opens fine on Mac but parsing fails. Code-point view shows 13 10 (CRLF) where the parser expects just 10 (LF). Convert line endings to fix.

The look-alike Unicode bug. Cyrillic 'а' (1072) looks identical to Latin 'a' (97). Phishing URLs and homograph attacks exploit this. Username "admin" with Cyrillic 'а' passes visual review but fails string compare to legitimate "admin". Code-point view exposes the mismatch.

Common Operations

Caesar cipher / ROT13. Shift each letter's code by N, wrap around. The ascii tool helps inspect the transformation step by step.

Sorting by ASCII. ['apple', 'Banana', 'cherry'].sort()['Banana', 'apple', 'cherry'] because B (66) < a (97). Surprising? The code points explain it.

Building char-by-char hashes. Some hash functions multiply by code points. The output you see depends on which codes the input has.

Character class regex. [A-Z] means "any character with code 65-90". [\u00C0-\u017F] means Latin Extended. Knowing the ranges gives you ranges in regex.

Encoding vs Code Point: Important Distinction

This tool shows code points, abstract identifiers of characters. It does not show bytes, how those code points get serialized for transmission/storage.

  • Code point 65 (A) in UTF-8: byte 0x41 (1 byte).
  • Code point 233 (é) in UTF-8: bytes 0xC3 0xA9 (2 bytes).
  • Code point 128512 (😀) in UTF-8: bytes 0xF0 0x9F 0x98 0x80 (4 bytes).

For byte-level debugging (HTTP request body, network packet capture), use a hex viewer or convert to base64.

Practical Workflows

  1. Debugging "two strings should be equal but aren't". Convert both to code points; compare element by element.
  2. Inspecting CSV/TSV separators. Is that "comma" actually a comma (44) or a different character?
  3. Validating regex character classes. Convert your character set to code points to verify the range.
  4. Building character-based algorithms. Caesar cipher, sorting, frequency analysis.
  5. Cleaning up paste artifacts. Spotting smart quotes, zero-width spaces, and non-breaking spaces in pasted text.

Privacy

The conversion is pure JavaScript, String.charCodeAt() and String.fromCharCode() running locally. Input text and code-point output never leave your browser. Debug strings containing tokens, IDs, or PII can be inspected safely.

You Might Also Need