Metro 2 File Viewer

What it is

The Metro 2 File Viewer is a free, browser-only tool that opens and decodes Metro 2 credit reporting files. Drop in a fixed-width .dat file or a CSV / Excel export and the viewer renders every record, every segment, and every field with plain-English labels pulled from the CDIA Credit Reporting Resource Guide (CRRG). It also runs a fast set of structural validations and tells you whether the file would survive bureau intake on the basics.

The viewer is open to the public — no account, no sign-up, no credit card. You can use it indefinitely as a reference tool.

The privacy promise

Your file never leaves your browser. The parser, decoder, and validator are all pure JavaScript that run inside your tab. There is no /api endpoint behind the upload box and no analytics beacon that includes file contents. If you want to verify this yourself, open your browser's DevTools, switch to the Network tab, drop a file, and watch: zero outbound requests fire after the page loads.

We chose this design specifically because credit-reporting professionals routinely need to inspect production files that contain PII (Social Security Numbers, dates of birth, addresses). Uploading those files to a third-party site to "view" them is a compliance nightmare. The viewer eliminates that risk.

When to use it

The viewer is designed for four recurring jobs:

• Debug a file you just generated. You ran your Metro 2 generator, downloaded the output, and want to confirm the HDR dates, trailer counts, and a couple of base records look right before you ship it to a bureau.
• Sanity-check a file from a vendor or processor. A servicer sent you their monthly file and you need to spot-check that account numbers, status codes, and the Payment History Profile (PHP) match what their dashboard shows.
• Train a new team member. Open a sample file and walk through it segment by segment — the inline CRRG descriptions mean you don't have to keep a 400-page PDF open on the side.
• Diagnose a bureau rejection. The bureau sent back "rejected: invalid ECOA code on line 47." Drop the file in, scroll to record 47, and the offending field is highlighted with the allowed values listed inline.

How to open the viewer

Visit metro2.switchlabs.dev/metro2/file-viewer. No login, no email gate, no popup. The page loads, you see the drop zone, and you can immediately drag a file onto it. Bookmark the URL if you use it often.

If you're already signed into your Metro2 account, the viewer still works the same way — it doesn't associate the file with your account in any way. Think of it as a stand-alone utility that happens to live on the same domain.

Uploading a file

Supported formats

• Fixed-width Metro 2 — .dat or .txt. The parser reads the 4-byte Record Descriptor Word (RDW) at the start of each record to figure out the record length, then slices the 426-byte base segment off the front and walks the remaining bytes looking for J1, J2, K1, K2, K3, K4, L1, and N1 segment identifiers.
• CSV — .csv. Field mappings are auto-detected (account number, status code, date opened, etc.). Common delimiters (comma, semicolon, tab, pipe) are detected automatically — you don't need to tell us which one your export used.
• Excel — .xlsx or .xls. The first sheet is parsed; column headers are matched to Metro 2 fields the same way as CSV.

How to upload

1. Drag and drop. Drag a file from Finder / Explorer onto the dashed drop zone. The zone highlights blue while a file is hovering.
2. Click to choose. If drag-and-drop is awkward (some remote-desktop tools block it), click anywhere inside the drop zone to open the native file picker.

File size cap

The viewer accepts files up to 50 MB (roughly 100,000 base records). Above that size, browsers start to stall the main thread and the page becomes unresponsive. If your file is larger, sign up and use the server-side validator — there's no record cap there.

If you upload a file that exceeds the cap or has an unsupported extension, the viewer shows a red error banner under the drop zone and nothing is parsed.

What you'll see

Once the file is parsed (usually under a second for typical monthly files), the page renders four blocks:

1. File summary card

The top card shows information lifted from the HEADER (HDR) and TRAILER (TR) records:

• Reporting period — the activity date from the HDR (the "as-of" date for the file).
• Furnisher name & Program Identifier — the company submitting the file.
• Record counts — the count declared by the TR record vs. the count we actually parsed. A mismatch is flagged here in red.
• Overall pass / fail badge — green if zero structural errors were found, yellow if there are warnings only, red if errors were found.

2. Record list

A virtualized list of every base record in the file. Each row is collapsed by default and shows a one-line preview:

#1   Acct 1234567890   Status 11 (Current)   Bal $4,250   J1 K1

A sticky filter bar at the top of the list lets you filter by status code, show errors only, or jump to an account number. Click any row to expand it.

3. Expanded record (segments & fields)

When you expand a record, you see one tab per segment:

• Base — the 426-byte mandatory segment containing the account number, balances, dates, status, ECOA, consumer name, address, SSN, DOB, and the Payment History Profile.
• J1 — additional consumer (e.g. a joint borrower). Same name / SSN / DOB structure as the base segment's consumer block.
• J2 — additional consumer with a separate address.
• K1 — original creditor name (used when the account was sold or transferred).
• K2 — purchased portfolio identifier (used by debt buyers).
• K3 — mortgage information (MIN, agency identifiers).
• K4 — specialized payment information (deferred balance, balloon).
• L1 — account number / identification number change.
• N1 — employment information.
• BS / TR — Block Summary and Trailer are rendered separately at the top and bottom of the file summary.

Inside each segment tab is a three-column table:

Hover the field name to see the full CRRG description. Click it to deep-link into the Metro 2 field reference for that field. Status codes, ECOA codes, portfolio type, and other coded values render the decoded meaning inline, plus a badge that links to the corresponding status-code page.

4. Payment History Profile grid

The 24-character Payment History Profile (field #27, offset 127) is rendered as a 24-cell color-coded grid below the base segment table. Each cell represents one month, newest on the left, going back 24 months. Greens are paying-as-agreed (0, B, D, E), yellows are 30 / 60 / 90-day late (1, 2, 3), reds are 120+ / 150 / 180+ late (4, 5, 6), purple is charge-off / collection (G, H, J, K, L), and grey is no data (-). Hover any cell for the month label and the raw character.

See the Payment History Grid help guide for the full PHP character map and tips on spotting bad strings.

5. Validation panel

A sticky right-rail panel summarizes the structural validation: counts of errors and warnings, plus a clickable list of each issue. Clicking an issue scrolls to the offending record and highlights the field.

Validation

The viewer runs a subset of the full Metro2 validation engine — the rules that are fast enough to run in the browser on every keystroke and don't need any external lookups.

Rules that run client-side

• File structure — exactly one HEADER as the first record, exactly one TRAILER as the last record, no stray records before / after them.
• RDW vs. actual length — the Record Descriptor Word at the front of each record must match the actual byte length of that record.
• Trailer count cross-check — the base-record count declared in the TR must match the number of base records we parsed.
• Required fields populated — account number, consumer name, identification number, and identification number type (SSN / TIN / etc.) must all be present.
• Account status in the CRRG-defined set — codes like 11, 13, 71, 78, 80, 82, 84, 97, DA, DF are valid; anything else is flagged.
• ECOA code in the CRRG-defined set — 1, 2, 3, 5, 7, T, W, X, Z are valid; anything else is flagged.
• Date fields parseable — every Metro 2 date field must be a valid YYYYMMDD (or all-zero, where allowed).
• No future dates — date opened, date of last activity, date of last payment, etc. must all be ≤ today.
• FCRA 7-year obsolescence warning — accounts with a DOFD older than 84 months are flagged as a warning (not an error) because they're typically not allowed to be reported.

Pass / fail meaning

• Pass (green) — zero errors found. Your file survives the structural checks. It may still fail bureau-side business-rule validation; see below.
• Warnings (yellow) — no blocking errors, but something looks off. Common one: an account is past the 7-year FCRA window.
• Fail (red) — at least one structural error. Click into the validation panel to see specifics.

What the viewer does NOT check

The full Metro2 validation engine includes ~240 rules and the browser version runs roughly 15 of them. Specifically, the viewer does not run:

• Cross-segment business rules (e.g. K1 required when status code is sold / transferred, K2 required for purchased-from-another-source, mortgage K3 required for portfolio type M).
• Bureau-specific validation profiles (Equifax / Experian / TransUnion / Innovis quirks).
• Money-field consistency (balance vs. charge-off, scheduled monthly payment vs. terms duration).
• PHP string consistency with the account status and date of last activity.
• Compliance Condition Code combinations.

If you want the full suite, sign up for a free Metro2 account. Upload runs the complete validator and produces a downloadable report you can hand to your QA team or compliance officer.

Common questions

Is my file uploaded anywhere?

No. The parser and validator are pure client-side JavaScript. There is no /api endpoint backing the drop zone and no analytics event includes file contents. The page is statically rendered on Vercel; once it loads, you can disconnect from the internet and the viewer will still parse your file.

Does this validate against bureau rules?

Partially. The viewer runs the structural rules every bureau enforces (file structure, RDW, trailer counts, required fields, valid status / ECOA codes, valid dates). It does not run cross-segment business rules or bureau-specific quirks — those live in the full validation engine, which requires an account.

Can I edit a record and re-save the file?

Not currently. The viewer is read-only by design — it's a diagnostic tool, not an editor. If you need to fix a file and re-emit it, sign up and use the in-app Metro2 record editor; it handles RDW recalculation, trailer recounting, and re-validation automatically.

What's the file size limit?

50 MB, which is roughly 100,000 base records (a typical mid-sized furnisher's monthly file). Larger files start to stall the browser's main thread; if you need to inspect one, use the server-side validator.

Does it work offline?

Yes, once the page is loaded. The viewer makes no network calls during parse / decode / validate. If you frequently work in air-gapped environments, you can load the page once and then drop the network — it'll keep working.

Does it support all bureau response file formats?

Not yet. The viewer is specifically for Metro 2 input files (the file you send to the bureaus). Bureau response files (the file the bureau sends back with accepted / rejected counts) use a different layout and have a dedicated decoder coming in a future release.

Troubleshooting

The file won't parse — "short record" or "rdw-mismatch"

By far the most common cause: the file isn't actually a Metro 2 fixed-width file, or the line endings got mangled in transit. Quick checks:

• Open the file in a hex editor or VS Code with the invisible-characters option on. A real Metro 2 file is mostly printable ASCII with the first 4 bytes of each record being the RDW (a 4-character numeric like 0426 for a 426-byte record or larger for records with appended segments).
• Check the byte length of one record. A base-only record must be exactly 426 bytes (4-byte RDW + 422-byte base segment payload? — actually 426 total per CRRG). With one J1 it would be 526. With J1 + K1 it would be 660. If your records aren't multiples of these lengths, the file was probably re-saved by an editor that injected line endings or stripped trailing spaces.
• Line endings. Metro 2 uses no line endings — records are back-to-back with no \r\n between them. Some FTP transfers add CRLFs and break the byte alignment. If you suspect this, ask the sender to re-send in binary mode (or pull the file with curl --binary instead of cat > file.dat).
• UTF-8 BOM. A few exporters prepend a 3-byte byte-order mark to ASCII files. Strip it before re-uploading.

CSV file parses but every field is in the wrong column

The auto-mapper looks at the column headers in row 1 to figure out which column is the account number, which is the status code, etc. If your CSV has no headers (or the headers use abbreviations like acct_no instead of Account Number), the mapping may be wrong. Try renaming your headers to match standard CRRG field names, or use the in-app field mapping editor available after sign-up.

Viewer says PASS but the bureau rejected the file

This is expected. The free viewer runs only the structural rules a browser can handle quickly (file layout, RDW, valid codes, parseable dates). The bureaus run ~240 rules including cross-segment business logic and bureau-specific profiles. To run the full suite, sign up and upload the file there — you'll get the same rejection the bureau caught, pinpointed to the exact record and field.

Drop zone shows red error: "Unsupported file type"

Accepted extensions are .dat, .txt, .csv, .xlsx, and .xls. If your file has a different extension (e.g. .metro2 or no extension at all), rename it to .dat and try again — the parser sniffs the content, not the extension.

Drop zone shows red error: "File exceeds 50 MB"

Browsers start to stall around this size. Either split the file (most generators support per-portfolio file splits) or use the server-side validator after signing up.

The page is slow / unresponsive on a big file

For files near the 50 MB cap, parsing can take a few seconds and the record list is virtualized so only visible rows are rendered. If your browser tab feels frozen for more than 10 seconds, force- reload and try a smaller file. Chrome / Edge / Firefox all handle the limit fine; older Safari versions on iPad sometimes struggle past 20 MB.

Related guides

• AI Error Explanations — turn the validator's cryptic codes into plain-English explanations with one-click suggested fixes.
• Payment History Grid — full guide to the 24-month PHP visualization, character map, and tips for spotting bad strings before submission.