Why Java Code Runs Into the 7-bit Boundary
Standard ASCII covers decimal 0 through 127, and a Java char can hold every one of those code points as a 16-bit unsigned value, which is why an ASCII table is a natural reference while writing Java. Java's larger char range (0 to 65535) is built on top of that 7-bit foundation, so the moment you cast a char to an int, compare against a literal like 0x41, or rebuild a String from a byte stream, you are translating between visible characters and their integer codes. An ASCII table gives you that translation in one place, with the same code shown in decimal, hexadecimal, octal, and seven-bit binary so you can read whichever notation your source, your logs, or your protocol spec uses. The 128-row boundary is deliberate: standard ASCII is a 7-bit set per ECMA-6, and the same code points map to the same names in the Unicode Basic Latin chart.
For example, capital A is decimal 65, hexadecimal 0x41, octal 0o101, and binary 0b1000001 — a single row, written four ways. Keeping the radix prefixes explicit matches how Java itself accepts integer literals, which makes the table a natural companion to the language rather than a generic reference.
What the ASCII Table Tool Actually Shows
The ASCII Table lists exactly 128 rows for code positions decimal 0 through 127. Each row pairs a visible character or a control abbreviation with the same code in four notations: decimal, two-digit hexadecimal, three-digit octal, and seven-digit binary. Names follow the Unicode Basic Latin chart for graphic entries and the RFC 20 abbreviations for controls like NUL, HT, LF, CR, and DEL. A category tag — controls, punctuation, digits, uppercase letters, lowercase letters, Space, or Delete — narrows the view without hiding the rest.
The table is built and filtered entirely in your browser, so search terms and copied rows never leave your machine. That detail matters when you are debugging character data on a closed network, reviewing logs that may contain sensitive payloads, or simply want a fast lookup without uploading anything.
How to Look Up a Character's Code in the Table
- Open the table and scan all 128 rows, or type into the search box. Plain digits are read as decimal, so entering 65 lands on capital A. To force a different radix, prefix the value: 0x41 for hex, 0o101 for octal, 0b1000001 for binary — all three resolve to the same row.
- Search by description when you do not know the number. Terms like line feed, question mark, capital letter, or NUL all match. To search by a literal character, prefix with char:, so char:space or char:0 finds the exact entry you need.
- Pick a category to narrow the full set: controls, punctuation, digits, uppercase letters, lowercase letters, Space, or Delete. The complete set of matching rows stays visible, so nothing is silently truncated.
- Read the row to confirm decimal, hex, octal, and binary match what your Java code expects. Then select Copy to capture one full row in a readable text format for a code comment, a bug report, or a protocol note.
Search Syntax at a Glance
The search box accepts the same notations Java itself accepts, so you do not have to translate between tools. The table below pairs each input style with the kind of match it triggers.
| Search input | What it matches |
|---|---|
| 65 | Decimal code 65 (capital A) |
| 0x41 | Hexadecimal code 0x41 (capital A) |
| 0o101 | Octal code 0o101 (capital A) |
| 0b1000001 | Binary code 0b1000001 (capital A) |
| char:space | The literal space character (decimal 32) |
| NUL | RFC 20 control abbreviation for decimal 0 |
| line feed | Description or full name for decimal 10 |
Pick the form that matches whatever notation your code, your stack trace, or your reference document is already using.
Mapping the Table to Java's Primitive Types
Once you have a row, the next question is how it fits into a Java primitive. ASCII is small enough that every relevant Java type can hold it, but the types do not behave the same way when you cast, especially around sign extension. The quick comparison below shows where each primitive lands on the 7-bit range.
| Type | Range | How it relates to ASCII |
|---|---|---|
| char | 0 to 65535 (unsigned 16-bit) | Every ASCII code point is a valid char |
| byte | -128 to 127 (signed 8-bit) | Decimal 0 to 127 fit; casting to int sign-extends negative values |
| int | -2,147,483,648 to 2,147,483,647 (signed 32-bit) | Holds the full decimal code with no overflow |
| String | A sequence of char values | A String built from ASCII bytes is identical to its Unicode form |
Stick to int when you want a clean unsigned view of the code; reach for byte only when the API you are calling — a socket read, a file channel, a binary protocol — actually delivers bytes.
Using a Table Row Inside Java Code
The fastest way to make the table useful is to anchor one row in your head and run a round trip through the language. Capital A is a convenient anchor because every radix notation points at the same integer.
Open the ASCII Table and confirm the row for decimal 65: it shows the visible character A, hexadecimal 0x41, octal 0o101, and seven-bit binary 0b1000001. In Java, the matching round trip looks like the expressions below — every line compiles to the same int value, 65, and the character back round-trips cleanly because Java's char is unsigned and the ASCII range fits entirely inside it.
- char letter = 'A'; sets letter to the character A.
- int code = (int) letter; produces 65.
- char back = (char) code; returns 'A'.
- int inHex = 0x41; compiles to 65.
- int inOctal = 0o101; compiles to 65.
- int inBinary = 0b1000001; compiles to 65.
The four numeric literals confirm that the radix prefixes the table uses (0x, 0o, 0b) are exactly the prefixes the Java compiler accepts, so the row can be lifted straight into source code without rewriting. The same anchor works for any other printable letter or digit you look up, which makes the table double as a cross-reference between Java's integer-literal syntax and the printed characters in a user-facing string. For a broader walk through Java-specific casting, validation, and stream work, see the Java-focused ASCII reference guide.
Control Codes, Line Endings, and Encoding Limits
Decimal 0 through 31 and decimal 127 do not have ordinary printable glyphs, which is why the table shows RFC 20 abbreviations like NUL, HT, LF, CR, and DEL alongside the integer codes. That distinction matters in Java because the language treats these code points as valid chars but most rendering libraries leave them invisible or substitute placeholders. When you see LF (decimal 10) in a network trace and CR (decimal 13) in a Windows text file, you are looking at two different conventions for the same problem — ending a line — and the table tells you the codes but cannot tell you which convention your protocol expects.
Beyond decimal 127, the table intentionally stops. Standard ASCII is a 7-bit set, and bytes 128 to 255 are not ASCII at all. They belong to a separate encoding such as ISO-8859-1, Windows-1252, or CP437, and a raw byte value is not enough on its own to recover the intended character. The tool makes that limit explicit so it does not silently hand you ambiguous answers; if you need to decode higher bytes, identify the encoding that produced them first. Java's java.nio.charset API exposes the named encodings you would reach for next, and pairing that with the ASCII Table keeps the 7-bit lookup honest.