Why does an .nfo file look like garbage in Notepad or a browser?

Classic scene .nfo files were authored on DOS using code page 437, where byte values 128-255 map to box-drawing lines, blocks, and symbols, not the accented Latin letters or Unicode characters those same byte values mean under UTF-8 or Windows-1252. Reading the raw bytes with the wrong table turns every box-drawing border into mojibake.

Why doesn't this tool use the category's usual strict 7-bit ASCII validation?

Every other tool in this category enforces strict 0-127 ASCII because that's the whole point of the category. This tool is the deliberate exception: its entire purpose is correctly rendering the extended 128-255 CP437 range that real .nfo files rely on for their art, so it accepts and maps the full 0-255 byte range instead of rejecting anything above 127.

Why upload a file instead of just pasting the text?

Pasting text into a browser only gives you whatever Unicode characters your OS/browser already decoded the file's bytes into, which has usually already lost the original byte values. Uploading reads the file's raw bytes directly (via FileReader as an ArrayBuffer), so every byte 0-255 is decoded through the real CP437 table rather than through a lossy prior decoding step. Pasting is supported as a convenience for text that still has its original Latin-1 byte values intact.

Does this handle every possible .nfo file perfectly?

It handles the standard CP437 table faithfully, including tab, line feed, and carriage return treated as real whitespace/line breaks rather than their CP437 glyphs, which is how real .nfo viewers render them. A small minority of scene releases use ANSI escape codes for color inside their .nfo art (an .ans file, or an .nfo with embedded ANSI) — those escape sequences aren't interpreted here and will show as literal characters.

NFO File Viewer - Read Classic Scene .NFO Files Correctly

Overview

Introduction

Long before Unicode was universal, DOS-era "scene" software groups shipped every cracked game or app with an accompanying .nfo text file, ASCII art logo, group credits, and release notes, all drawn using IBM PC code page 437's extended character set for box borders and shading blocks.

Opening one of those files today in a modern UTF-8-only text editor shows a wall of question marks and mojibake where the art should be, because CP437's byte values 128-255 mean completely different characters under modern encodings.

What Is NFO File Viewer?

A byte-accurate viewer that decodes raw file bytes (or pasted Latin-1-preserved text) through the real CP437 table IBM shipped on the original PC, rather than treating the bytes as UTF-8 or Windows-1252.

It reads the uploaded file as raw bytes (not as pre-decoded text), which is what makes it possible to recover the original box-drawing and block characters instead of whatever a naive text read already mangled them into.

How NFO File Viewer Works

An uploaded file is read with `FileReader.readAsArrayBuffer`, giving direct access to every byte 0-255 exactly as stored on disk; pasted text is instead read character-by-character and each character's code point (assumed to be 0-255, i.e. still Latin-1-shaped) is treated as a raw byte.

Each byte is looked up in a hand-built 256-entry CP437 table: bytes 32-126 match plain ASCII, bytes 0-31 and 127 use CP437's control-picture glyphs (except tab/LF/CR, kept as real whitespace), and bytes 128-255 map to CP437's extended Latin letters, box-drawing lines, shading blocks, and symbols.

The decoded text is rendered in a dark-background monospace block so the box-drawing characters visually line up the way they did in a DOS console.

When To Use NFO File Viewer

Use it whenever you've downloaded or found a classic .nfo release file and it shows garbled characters instead of the intended ASCII/CP437 art in your normal text editor.

Also useful for viewing any other DOS-era CP437 text, batch file headers, BBS door-game text, or old shareware READMEs, that relies on the extended character range.

Often used alongside ASCII Table Generator and Hex to ASCII Converter.

Features

Advantages

Reads the file's actual raw bytes rather than trusting a prior (often wrong) text decoding, so nothing is lost before the CP437 table is even applied.
Implements the full 256-entry CP437 table, including the box-drawing and block-shading ranges that make .nfo art recognizable.
Renders output in a terminal-styled monospace block so alignment-dependent box art displays correctly.

Limitations

Does not interpret embedded ANSI color escape codes, some scene .nfo/.ans files use them for color; this tool shows the raw escape bytes as CP437 characters instead of rendering color.
Pasted (non-file) input depends on the browser/OS not having already destroyed the original byte values before the paste happened; a true byte-for-byte read is only guaranteed via file upload.
Byte 0x00 (NUL) is rendered as a blank space rather than any visible glyph, matching common CP437 viewer convention, though some references leave it undefined.

Examples

Decoding a double-line box border

Input

Bytes 201, 205×3, 187 (a top border row)

Output

╔═══╗

CP437 byte 201 is ╔, 205 is ═, and 187 is ╗, the classic double-line box-drawing set used in scene .nfo headers.

Plain ASCII passes through unchanged

Input

Bytes for "RELEASE NOTES"

Output

RELEASE NOTES

Bytes 32-126 are identical between CP437 and standard ASCII, so ordinary letters, digits, and punctuation render exactly as typed.

Best Practices & Notes

Best Practices

Prefer uploading the actual .nfo file over copy-pasting its contents from another program, since copy-paste can already have re-decoded the bytes through the wrong encoding before you ever see them.
If a file still shows unexpected characters after decoding, check whether it might use a different DOS code page (e.g. CP850) instead of CP437, they overlap heavily but diverge in a few extended-range positions.

Developer Notes

This is the one tool in the ascii category that intentionally does NOT call the shared `validateStrictAscii` 0-127 gate: its entire purpose is correctly rendering bytes 128-255, so restricting to 7-bit ASCII would defeat the tool. The CP437 table is hand-built as two lookup arrays (control codes 0-31, extended range 128-255) plus the identity mapping for 32-126, with tab/LF/CR special-cased to real whitespace in `decodeCp437Bytes()` since real .nfo files use them as line control, not art, even though the full CP437 font technically defines glyphs for those three positions too.

NFO File Viewer Use Cases

Reading classic scene-release .nfo files whose ASCII art shows as mojibake in a normal editor
Recovering box-drawing art from any DOS-era CP437 text file
Verifying which raw bytes a mysterious garbled text file actually contains

Common Mistakes

Opening a .nfo file directly in a UTF-8 text editor and assuming it's simply corrupted, when it's actually intact CP437 bytes being misread.
Pasting already-mangled text (re-decoded through the wrong encoding by another program first) and expecting a clean recovery; only the original file bytes decode perfectly.

Tips

If the output still looks wrong after uploading, double check the file isn't UTF-8 to begin with, some modern re-releases of old .nfo content are saved as UTF-8 and don't need CP437 decoding at all.
Box-drawing rows should line up vertically in the monospace output; if they don't, the file's line endings may be inconsistent rather than the byte decoding being wrong.

NFO File Viewer