## TL;DR
Corrupted exports are usually truncated downloads, encoding mismatches, or the wrong format choice, not actual corruption. Check the file size first (a 2KB "spreadsheet" is a failed download), then try opening in a plain text editor to see what is really inside. Re-export with explicit encoding and format options. Genuine corruption is rare; mislabeled files are common.

## The query

```text
my export is corrupted: troubleshooting checklist
```

## Use this when

- Users report exports that will not open
- Exported files show garbled text or cut off
- "Corrupted file" tickets after exports
- Writing export troubleshooting docs

## Not for

- Building export features
- Database corruption
- File-format design
- Import troubleshooting (different checklist)

## Steps

### 1. Check the file size for sanity

A spreadsheet export that is 2KB is not corrupted; it is an error page saved with a spreadsheet extension. Compare against a known-good export size. Tiny files mean the download failed, not the data.

Expected output: file size compared to expected.

### 2. Open it in a plain text editor

Text editors show what is really in the file: an HTML error page, half a CSV, or actual data. This one step diagnoses most "corruption" in seconds.

Expected output: the true file contents identified.

### 3. Check encoding explicitly

Garbled characters (mojibake) mean the file is fine but read with the wrong encoding. Re-export specifying UTF-8, and tell the user to import specifying UTF-8. Excel on Windows defaults to local encoding and mangles UTF-8 CSVs.

Expected output: encoding specified on both export and open.

### 4. Check for truncation

Row counts: does the file have all rows. Large exports get cut by timeouts, browser limits, or email attachment caps. If it is truncated, export in date ranges or use the API/bulk export.

Expected output: row count verified complete or truncation confirmed.

### 5. Re-export with different options

Different format (CSV instead of XLSX), smaller range, or the async export that emails a link. One variable at a time. Note which combination works for the ticket record.

Expected output: a working export configuration.

## Template: the checklist reply

```text
Let us figure out what is actually in that file, [Name]:

1. How big is the file? If it is only a few KB, the download itself failed.
2. Can you open it in a plain text editor (Notepad/TextEdit) and tell me what the first few lines look like? That shows whether it is real data, an error page, or a truncated file.
3. If the text looks garbled (weird symbols instead of letters), it is an encoding mismatch. I will re-export it as UTF-8 and walk you through opening it that way.
4. How many rows should it have, roughly? Large exports sometimes get cut off.

Send me what you find and I will get you a clean file.
```

## Variant phrasings

### exported file will not open

Steps 1 and 2. Size check, then text editor.

### csv export garbled characters

Step 3. Encoding mismatch, almost always.

### export cut off missing rows

Step 4. Truncation; export in ranges.

## Why it works

"Corrupted" is a user diagnosis, not a fact. The checklist replaces it with evidence: size, true contents, encoding, completeness. Each check is fast and each rules out a common cause, so the ticket converges instead of bouncing between "try again" replies.

## Edge cases

- Password-protected exports: some tools encrypt and the user does not know the password. Check.
- The export contains formulas, not values: re-export with "values only."
- Email attachment size limits silently truncating: use the download link instead.
- Genuinely corrupted source data URIs rare, but if two export formats both garble the same rows, escalate to engineering.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-UqNMMdRoTLcXQpXeSi_Ig