← LoadfileKit / Guides / DAT viewer

Opening a DAT file: your options, ranked

You received a production's metadata file. Here's how to actually look at it.

A DAT is structurally a CSV wearing a costume: fields separated by ASCII 20 (or the visible ¶ variant), every value wrapped in þ, internal line breaks written as ®. Open it with the wrong assumptions and you get one garbled column, or a file that looks like line noise. The DAT format guide explains the grammar; this page is about the practical "I just need to see what's in here" paths.

Option 1 — in the browser, nothing installed

The LoadfileKit converter opens a DAT as a table: encoding detected on load, qualifier-aware field splitting, ® rendered as real line breaks, header row recognized. Nothing is uploaded — the parse happens locally — so it is safe for produced data under confidentiality. From there you can export CSV/Excel for editing and convert back. This is the fastest path and the one that doesn't corrupt anything.

Option 2 — Excel, done carefully

Double-clicking a .dat fails: Excel assumes commas. Either convert DAT→CSV first (then open, edit, convert back), or use Excel's Data → From Text/CSV import with a custom delimiter — workable for a quick look, but Excel's import UI handles exactly one delimiter character, re-encodes on save, strips leading zeros from Bates-looking numbers, and rewrites dates. Fine for reading; risky for round-tripping. See the Excel → DAT/OPT guide for the trap list.

Option 3 — hex editor, for diagnosis

When the question is "why won't this parse", a hex editor on the first line answers it: you'll see whether the qualifier is a lone FE (Windows-1252) or a C3 BE pair (UTF-8), and where the field delimiter actually sits. This is the byte-level check from the encoding trap guide. Tedious for reading content, indispensable for debugging.

What a trustworthy DAT viewer must handle

BehaviorWhy it matters
Encoding detection before parsingþ is 0xFE in CP1252, C3 BE in UTF-8 — assume wrong and boundaries vanish
Qualifier-aware splittingCustodian names ("Smith, John") contain commas; splitting on the delimiter without honoring þ shreds them
® as newline, doubled þ unescapedOtherwise text fields display as run-ons and escaped characters display doubled
Header row recognitionField names vary by producer; positions must never be assumed
Field-count validationA record with fewer fields than the header is the first symptom of a shredded file
Local-only processingProduced data is often confidential; a viewer that uploads it is a risk you don't need

Which option when