A report containing thousands of table rows needs a different investigation from a short page carrying one enormous embedded image. Repeatedly opening both in a preview tool hides that distinction.
Start with the file you actually received
Keep the original filename, folder, and accompanying assets. Make a working copy and note its size. If it arrived in a ZIP, extract the complete archive before trying to render it; a missing asset folder is a separate problem from file size.
Open the copy in a text editor. Leave formatting and automatic cleanup off until you know the file opens reliably. A generated report can be one very long line, and running a formatter immediately creates additional work before you have located the content.
Search for a distinctive heading or a known record identifier. If the goal is to confirm one entry, a targeted text search may be enough. The HTML text editor guide explains how to open source instead of its rendered appearance.
Identify what accounts for the size
Look for the structure around the largest repeated regions. These are diagnostic clues, not measurements of your particular file:
| Source contains | Next question |
|---|---|
| Many repeated table rows | Can the exporter produce a date range or separate reports? |
Long data:image/... values |
Can the exporter retain images as accompanying files? |
| Large script data arrays | Is the visible table generated from those records? |
| Repeated complete sections | Was more than one export concatenated accidentally? |
Do not delete a long value merely because it looks disposable. It may be the only copy of a chart or attachment. Regenerate a smaller report from the originating system when possible, retaining the complete export for reference.
Read only a prefix when building an inspection tool
For developers who already have a selected browser File, a bounded read can answer basic source questions without reading the entire file into one string:
// file is an existing File selected by the user.
const prefix = await file.slice(0, 64 * 1024).text();
console.log(prefix);
This reads the first 65,536 bytes. It neither renders the report nor establishes that the rest is valid. A cutoff can split an encoded character or an HTML element, and the required record may occur much later. The example illustrates Blob slicing; it is not a complete file viewer or a full-document search.
If you need the rendered report
Open one working copy in a browser and observe where it fails: before any text appears, while the table is being created, or when a filter runs. If the tab remains responsive enough, Chrome's Task Manager can show its memory use, while DevTools provides more detailed investigation.
Avoid loading the same report into several tabs to compare attempts. Record the failing operation and ask the exporter for a narrower range or a paginated version. For a developer investigating script or layout work, page performance measurement covers the next step.
Keep the complete original and label any reduced version with its actual coverage, such as “January records only.” A smaller page can help someone read a subset, but it should never silently replace the full report.