ASCII World

Our Methodology

Our Approach

ASCII World maintains character encoding data for over 2,500 code points across multiple encoding standards. Every value on this site - decimal, hexadecimal, octal, binary, HTML entity, and Unicode mapping - is sourced directly from the governing specification and cross-referenced against at least one independent implementation before publication.

We treat encoding data the same way a reference library treats its catalog: each entry must trace back to an authoritative source, and discrepancies between sources are investigated rather than averaged. When two specifications disagree (as ISO 8859-1 and CP1252 do for bytes 0x80 through 0x9F), we document both mappings and explain the difference rather than choosing one.

Primary Sources

All character encoding data on ASCII World is derived from these official specifications and registries:

  • ANSI X3.4-1986 - The definitive standard for the 128-character ASCII set. This is the final revision of the original 1963 ASA X3.4 standard that established the code assignments still used today.
  • ISO/IEC 646:1991 - The international version of the ASCII standard. We reference this for national variant differences (such as the British pound sign at position 0x23 in the UK variant).
  • ISO 8859 series (Parts 1 through 16) - Each part defines a specific 8-bit extension. Our ISO-8859-1 table covers all 191 assigned characters from Part 1, with unmapped positions (0x80-0x9F) clearly marked as undefined in the standard.
  • The Unicode Standard, Version 15.1 - Published by the Unicode Consortium, this defines the code point assignments, character names, and properties we use for Unicode mappings. We update our data within 60 days of each new Unicode release.
  • IBM Code Page Documentation - IBM's CDRA (Character Data Representation Architecture) documents define CP437 and related code pages. We reference IBM's official GCSGID/CPGID registry for code page 437 mappings, including the 16 box-drawing characters and the graphical characters unique to DOS.
  • Microsoft Code Page References - Windows-1252 and other Windows code pages are documented in Microsoft's MSDN archives. Our CP1252 data matches the mapping table published in Microsoft's specification, including the 27 characters that differ from ISO 8859-1 in the 0x80-0x9F range.
  • IANA Character Set Registry - The Internet Assigned Numbers Authority maintains the canonical list of character set names and aliases. We use IANA's preferred MIME names throughout the site for consistency.

Verification Process

Raw specification data goes through a three-step verification pipeline before it appears on the site:

  1. Source extraction - Code point values are extracted directly from the official specification document. For ASCII, this means the hexadecimal assignments from ANSI X3.4-1986 Table 1. For Unicode, we parse the Unicode Character Database (UCD) files published at unicode.org.
  2. Cross-reference check - Each extracted value is compared against an independent implementation. For example, CP437 mappings are verified against Python's codecs module (which implements IBM's specification independently) and against the ICU library's conversion tables. Any discrepancy triggers a manual review against the original IBM documentation.
  3. Boundary and edge case audit - We specifically test boundary conditions: code point 0 (NUL), code point 127 (DEL), the undefined region 0x80-0x9F in ISO 8859-1, the euro sign at 0x80 in CP1252, and the full surrogate pair range in Unicode. These are the positions where encoding errors most commonly occur in real software.

Encoding comparison tables (such as CP1252 vs. ISO-8859-1) are generated programmatically from verified source data and then spot-checked at every position where the two encodings differ.

Tool Accuracy

Each converter tool on ASCII World is validated against a test suite of known input-output pairs before release. The test suite covers:

  • Standard conversions - Single characters, full strings, and multi-line input. For the Text to ASCII converter, this includes verifying that "Hello" produces "72 101 108 108 111" in decimal and "48 65 6C 6C 6F" in hexadecimal.
  • Boundary values - Code 0 (NUL), code 31 (last control character), code 32 (space), code 126 (tilde, last printable ASCII), and code 127 (DEL). These are the values most likely to cause off-by-one errors.
  • Format edge cases - Leading zeros in hex and octal output, whitespace handling in binary input, and proper Base64 padding with "=" characters. The Base64 encoder is tested against RFC 4648 test vectors.
  • Invalid input - Non-ASCII characters, empty input, and malformed sequences. Tools display clear error messages rather than producing silent garbage output.

Content Review

Articles, glossary entries, and reference pages are written by contributors with direct experience in systems programming, network protocols, or internationalization engineering. Each piece of content follows these standards:

  • Technical claims cite a specific specification section, RFC number, or Unicode Standard chapter. For example, our UTF-8 article references RFC 3629 sections 3 and 4 for the byte sequence rules.
  • Code examples are tested in the stated language version before publication. Python examples target Python 3.10+; JavaScript examples target ES2020.
  • Historical claims (such as the date of ASCII's first publication or the founding of the Unicode Consortium) are verified against primary sources rather than secondary encyclopedic references.

Corrections and Updates

Despite our verification process, errors can occur. If you spot an incorrect code point value, a wrong character name, a broken tool conversion, or a factual error in an article, please report it through our contact page or email [email protected].

Include the page URL, the specific value you believe is incorrect, and (if possible) a reference to the correct value from an official specification. We investigate all reported errors and typically publish corrections within 24 hours of confirming the issue.