DEV Community: Foretaste

Why Browsers Force File Downloads and How to Preview Binary Data Client-Side

Foretaste — Tue, 13 Oct 2026 04:26:27 +0000

Every developer knows this scenario. You are browsing GitHub, an internal documentation portal, or an S3 bucket console. You see a link to a document, a dataset, or a config file. You only want to inspect it for five seconds to check a column name, read a changelog, or verify a number.

You click the link. Instead of opening cleanly in a new browser tab, the browser triggers an immediate download to your hard drive.

By Friday afternoon, your Downloads folder contains twenty files you never intended to keep: three versions of a customer export, five PDFs, and an assortment of .sqlite, .parquet, and .docx files.

Here is why browsers behave this way, why blindly downloading files is a real security concern, and how you can parse and preview complex binary formats completely in-browser without sending a single byte to an external server.

Why Browsers Force Downloads Instead of Showing Files

Browsers do not download files by accident. They download them when one of three web standards tells them to:

1. The Content-Disposition Header

Web servers often send this header in their HTTP responses:

Content-Disposition: attachment; filename="report-q3.xlsx"

The keyword attachment instructs the browser to treat the incoming payload as a file download rather than rendering it in the viewport, regardless of whether the browser natively knows how to display the format.

2. The HTML5 Download Attribute

If an HTML link has the download attribute:

<a href="/data/analytics.parquet" download>Download Dataset</a>

The browser obeys the author's directive and routes the incoming stream directly to the local disk.

3. Generic or Missing MIME Types

If an S3 bucket or API endpoint sends a file with Content-Type: application/octet-stream or no MIME type at all, the browser treats it as unknown raw binary data. Because it does not know what renderer to invoke, it dumps the stream into your Downloads directory.

The Hidden Security and Privacy Risks

Forced downloads are not just an annoyance. They create real security and privacy risks.

The SVG Script Execution Trap

Most people treat SVG files like ordinary images such as PNGs or JPEGs. But SVGs are XML documents, and XML allows embedded <script> tags, inline event handlers like <rect onload="...">, and external resource fetches.

If you open an untrusted SVG directly in a browser tab or download it to your local environment, any JavaScript embedded inside that SVG executes within the origin context. This can expose session cookies or trigger cross-site scripting (XSS).

To render an SVG safely, it must be isolated inside a sandboxed iframe with scripts explicitly disabled:

<iframe sandbox="" srcdoc="...sanitized SVG markup..."></iframe>

Magic Bytes vs. File Extension Spoofing

Relying on a file extension in a URL is unsafe. An attacker can name a link financial_report.pdf while serving a Windows binary or a malicious script.

A secure preview engine does not trust URL endings. Instead, it inspects the first few magic bytes using a 512-byte HTTP Range request before deciding what to do with the file:

async function detectRealMimeType(url: string): Promise<string> {
  const headBytes = await fetchByteRange(url, 0, 512);

  // Check PDF signature: %PDF- (0x25 0x50 0x44 0x46 0x2D)
  if (startsWith(headBytes, [0x25, 0x50, 0x44, 0x46, 0x2d])) {
    return 'application/pdf';
  }

  // Check SQLite format 3 signature: 'SQLite format 3\0'
  if (startsWith(headBytes, [0x53, 0x51, 0x4c, 0x69, 0x74, 0x65, 0x20, 0x66, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0x20, 0x33, 0x00])) {
    return 'application/x-sqlite3';
  }

  // Check Parquet magic bytes: 'PAR1' (0x50 0x41 0x52 0x31)
  if (startsWith(headBytes, [0x50, 0x41, 0x52, 0x31])) {
    return 'application/vnd.apache.parquet';
  }

  // Check ZIP / Office container: 'PK\x03\x04'
  if (startsWith(headBytes, [0x50, 0x4b, 0x03, 0x04])) {
    return 'application/zip';
  }

  return 'application/octet-stream';
}

The Third-Party Cloud Viewer Danger

When faced with files they cannot open natively, many developers and office workers turn to free online viewers like "Free Online SQLite Viewer" or "Docx to HTML Online".

This is a massive privacy risk. Uploading internal company database exports, financial sheets, or customer lists to random third-party cloud servers breaks confidentiality agreements and leaks private data.

The only safe way to preview remote files without downloading them is to do all the parsing client-side, inside your own browser tab.

Peeking Into Complex Formats Locally

Modern browsers are capable of running complex binary parsers and WebAssembly runtimes entirely in memory. Here is how three major formats can be previewed without downloading full files.

1. Parquet Datasets: Reading the Footer

Apache Parquet is the standard format for big data analytics. A single Parquet file can easily be 500 MB or 2 GB.

Similar to ZIP files, Parquet stores its file metadata in a footer at the very end of the file. The last 4 bytes of any valid Parquet file are the magic characters PAR1. Immediately preceding those 4 bytes is a 4-byte little-endian integer indicating the byte length of the metadata footer.

[ Data Page 1 ]
[ Data Page 2 ]
...
[ FileMetaData (Thrift encoded) ]
[ 4-byte Footer Length ]
[ 4-byte Magic 'PAR1' ]

To inspect schema, column types, row counts, and compression codecs for a 2 GB Parquet file, you only need to fetch the last few kilobytes over an HTTP Range request:

async function readParquetFooter(url: string, fileSize: number) {
  // 1. Fetch the last 8 bytes to get the footer length
  const tail = await fetchByteRange(url, fileSize - 8, fileSize);
  const view = new DataView(tail.buffer, tail.byteOffset, 8);
  const footerLen = view.getUint32(0, true);

  // 2. Fetch only the metadata footer bytes
  const footerBytes = await fetchByteRange(url, fileSize - 4 - footerLen, fileSize - 4);

  // 3. Decode Thrift metadata in browser memory
  return decodeParquetMetadata(footerBytes);
}

You can view column names, data types, and row group counts instantly, without transferring the underlying gigabytes of column data.

2. SQLite Databases: Paging Tables Without Full Downloads

If you encounter a remote SQLite database on an S3 bucket or a staging server, you do not need to download the whole database file to run SELECT queries or inspect the schema.

The SQLite binary header is exactly 100 bytes at offset 0. It tells you the database page size (typically 4,096 bytes). Page 1 always contains the master sqlite_schema table.

By making targeted HTTP Range requests for individual 4 KB pages, you can parse B-tree nodes in browser memory. When a user requests table names, you read Page 1. When they page through the first 50 rows of a specific table, you fetch only the specific leaf page corresponding to those rows.

3. Paging Giant CSV Files

CSV files do not have indexes at the tail. If someone gives you a 150 MB CSV file with 500,000 rows, rendering 500,000 DOM elements will instantly crash your browser tab.

The correct approach is streaming with offset indexing:

Stream the CSV bytes once to record the byte offsets of every 200th line.
Store only those numeric offsets in memory (a few kilobytes of array data).
Discard the raw text payload.
When the user navigates to page 45, request only the byte range between offset N and offset N+1 using an HTTP Range request.

Row 500,000 costs the exact same memory and rendering time as row 1.

How to Handle This in Real Workflows

To make this seamless in everyday development, you need an extension that intercepts link interactions before the browser's download manager takes over.

I built this into Foretaste, a browser extension available for Chrome, Edge, and Firefox.

Here is how it works:

You right-click any link pointing to a file on the web.
Foretaste sends an initial HTTP Range request to inspect magic bytes and headers.
It opens an isolated preview tab inside your browser and renders the file using local parsers (Preact, WebAssembly, and native Streams).
For ZIP archives, it reads the Central Directory and lets you browse or extract single files.
For PDFs, Word documents, Excel workbooks, Parquet files, and SQLite databases, it renders the contents on the fly.
Crucially, zero file bytes are uploaded to any server. There is no backend processing service. Everything stays in your browser memory.

Conclusion

The web was originally built to let us read and browse documents, not force us into managing local filesystem clutter.

By taking advantage of modern HTTP Range requests, browser Streams, and client-side binary parsers, we can preview remote files instantly and safely, without wasting bandwidth or compromising our privacy.

Listing a 40 MB ZIP Over HTTP by Reading Only 67 KB of It

Foretaste — Wed, 07 Oct 2026 12:14:05 +0000

Normally, if you want to see what is inside a remote .zip file on the web, you have to download the whole file to your disk or upload it to a cloud tool. If the archive is 40 MB or 1 GB and you only need to check one file name or grab a single text file, downloading the whole thing is slow and wastes bandwidth.

Here is how you can read the entire directory listing of a remote ZIP by fetching only ~67 KB over HTTP using byte range requests, without downloading the full archive.

Key Metric / Real Measurement

Tested against a remote server logging all request payloads:

Archive total size: 40,013,838 bytes (~40 MB) with 10 files.
Bytes fetched to list all files: ~67 KB (0.17% of total archive size).
Overhead to extract a single file inside it: 97 bytes (local header + entry data).

Why this is possible

The ZIP format specification places the table of contents (called the Central Directory) at the very end of the file, not at the beginning:

[ local header + file data ] ... [ Central Directory ] [ EOCD (22 bytes) ]
                                 ^                     ^
                                 Table of contents     End of Central Directory

The last record in the file is the End of Central Directory (EOCD). It is 22 bytes long and contains:

Total number of entries in the ZIP
Byte size of the Central Directory
Byte offset where the Central Directory starts

(Note: A ZIP can have an optional trailing comment up to 65,535 bytes, so the EOCD is located somewhere within the last 22 + 65,535 = 65,557 bytes).

If the remote web server supports HTTP Range requests (Accept-Ranges: bytes), we can request just the tail of the file.

How it works step-by-step

Step 1: Fetch the tail (EOCD) with a Range request

Send an HTTP Range request for the end of the file. Most archives have no comment, so a 4 KB read is usually enough. If no EOCD signature is found, fall back to 65,557 bytes:

// Request the last 4096 bytes first
const FIRST_TAIL = 4096;
const LONGEST_TAIL = 22 + 0xffff; // 65557 bytes

let from = Math.max(0, size - FIRST_TAIL);
let tail = await fetchRange(url, from, size);
let at = findEOCD(tail); // scans backward for signature 0x06054b50

if (at < 0 && from > 0) {
  // Trailing comment present: fetch the full 65k tail
  from = Math.max(0, size - LONGEST_TAIL);
  tail = await fetchRange(url, from, size);
  at = findEOCD(tail);
}

Note: Always scan backwards for 0x06054b50 because that 4-byte sequence could randomly exist inside compressed payload bytes.

Step 2: Read the Central Directory

From the 22-byte EOCD record, pull the count, size, and offset:

const end = new DataView(tail.buffer, tail.byteOffset + at, 22);
const count    = end.getUint16(10, true);
const cdSize   = end.getUint32(12, true);
const cdOffset = end.getUint32(16, true);

Then send a second range request for cdOffset to cdOffset + cdSize (or slice it directly from memory if it was already included in the tail you fetched):

// Each record starts with 0x02014b50
while (p + 46 <= cd.length && view.getUint32(p, true) === 0x02014b50) {
  const flags      = view.getUint16(p + 8, true);
  const nameLength = view.getUint16(p + 28, true);
  const name       = new TextDecoder(flags & 0x0800 ? 'utf-8' : 'latin1')
                       .decode(cd.subarray(p + 46, p + 46 + nameLength));

  entries.push({
    name,
    packedSize: view.getUint32(p + 20, true),
    uncompressedSize: view.getUint32(p + 24, true),
    offset: view.getUint32(p + 42, true)
  });

  p += 46 + nameLength + view.getUint16(p + 30, true) + view.getUint16(p + 32, true);
}

This gives you the full file tree, file sizes, and offsets.

Step 3: Extract a single file on demand

When the user clicks on a specific file:

Fetch the 30-byte local header at entry.offset to determine the start of the compressed data.
Fetch only the compressed byte range (entry.packedSize).
Decompress in the browser using the native Streams API (no external libraries needed):

const stream = new Blob([packedBytes]).stream()
  .pipeThrough(new DecompressionStream('deflate-raw'));
const fileBytes = new Uint8Array(await new Response(stream).arrayBuffer());

Quick test with curl (Try it yourself)

You can verify this in your terminal on any remote ZIP:

# 1. Check if the server supports ranges (look for Accept-Ranges: bytes)
curl -sI https://example.com/large.zip | grep -i accept-ranges

# 2. Download only the last 65 KB of the archive
curl -s -r -65557 https://example.com/large.zip -o tail.bin

# 3. unzip will read the central directory directly from the tail
unzip -l tail.bin

Edge cases and limitations

Small files (< 100 KB): Two HTTP round trips to fetch 64 KB of an 80 KB archive take longer than a single GET request for the whole file.
Servers ignoring Range headers: Some servers or CDNs do not honor byte ranges and respond with 200 OK sending the whole file anyway.
ZIP64: Archives over 4 GB or with more than 65,535 files store offsets in a separate PK\x06\x06 record.
Tarballs (.tar.gz): Does not work on tar.gz archives because gzip streams do not have an index at the end and must be decoded sequentially from byte 0.

About the project

I implemented this technique in Foretaste, a lightweight browser extension that lets you right-click any file link to inspect ZIP contents, read documents (PDF, DOCX, XLSX), or view media directly in your browser without downloading.