How to Download a Website for Offline Use (and Why Modern Sites Break)

October 14, 2026

5 min readIncludes a tool comparison and copy-ready commands

Downloading a website used to be easy. Pages were HTML files, images and a stylesheet, and any downloader could follow the links and copy them. Today you can run a perfectly good downloader, open the result, and get a white page, a page with no fonts, or a hero with a black rectangle where the 3D used to be.

This guide covers the right tool for each job, then explains the three reasons modern sites break offline and how to fix each one.

Pick the right tool for the job

Start with what you need. Reading one article on a plane is a different job from archiving a client’s whole site or studying how an animated page was built.

One page, for reading: Save Page As or SingleFile

For an article, a recipe or documentation, you do not need anything heavy.

• Save Page As (Ctrl+S / Cmd+S → “Webpage, Complete”) writes an HTML file plus a folder of assets. Fine for simple pages; it often misses fonts and anything loaded late.
• SingleFile (a free extension for Chrome, Firefox and Edge) saves the page exactly as it is currently rendered into one self-contained HTML file. It is the best option for reading and archiving, because the copy opens anywhere. Scroll to the bottom before saving so lazy images load.

On a phone, Safari’s Reading List saves pages for offline reading on iPhone, and Chrome’s download button does the same on Android. Both are for reading, not for keeping a working copy.

A whole site: wget or HTTrack

To mirror many pages, use a crawler. wget is on most Macs (via Homebrew) and Linux machines, and in WSL on Windows:

wget --mirror --convert-links --adjust-extension \
     --page-requisites --no-parent https://example.com/docs/

• --mirror follows links recursively and keeps timestamps.
• --page-requisites fetches each page’s CSS, images and scripts.
• --convert-links rewrites links so they point at your local copy.
• --no-parent stops it climbing above the folder you gave it.

Add --wait=1 to be polite to the server. Fetching hundreds of pages as fast as possible is how you get rate-limited or blocked. HTTrack does the same job with a graphical interface on Windows, and the command-line version works anywhere:

httrack https://example.com/docs/ -O ./example-mirror

Both are excellent for documentation, blogs and server-rendered sites. Both share one blind spot, covered next.

Why modern sites break offline

Open a wget mirror of a React, Next.js or Webflow site and you will often see one of three failures. They have different causes, so it helps to know which you are looking at.

1. The page is built by JavaScript

wget and HTTrack read HTML and follow links. They never run scripts. On a single-page app the HTML is little more than <div id="root"> and a script tag. Worse, modern bundlers split code into chunks the page requests only while running (import() calls), so the crawler never even learns those files exist. The fix is to capture the page in a real browser after it has run.

2. Assets live elsewhere, or load late

Fonts often come from a font CDN, images from an image CDN, and 3D models from a storage bucket, all on different domains. wget skips other hosts unless you add --span-hosts with a --domains list. Lazy-loaded images only request their real source when scrolled into view, which a crawler never does. And files requested from JavaScript (a texture, a JSON scene) are invisible to anything that does not run the page.

3. You opened it as a file

This one catches almost everyone. Double-clicking index.html opens it as file://. Browsers treat that as a special, locked-down origin: ES module scripts, fetch() calls and some font loads are blocked by CORS. The site looks broken even though every file is present. Serve the folder instead:

cd example-mirror
npx serve .            # or: python -m http.server 8000

Then open the localhost address it prints. We wrote up a real case, where a captured Webflow + GSAP site looked broken until it was served properly, in why a captured site looks broken until you stop opening it as a file.

Capturing the page as it actually runs

For sites built mostly from JavaScript (anything with real animation, WebGL, or a React front end), the reliable approach is to record what a real browser loads while the page runs, rather than guess from the HTML. That is what a runtime capture does. Enrichr loads the page in a browser, scrolls it so lazy assets fire, records every request (chunks, fonts, textures, models), rewrites the URLs to local paths and packages the result as a zip.

Two honest caveats. First, any running copy still needs to be served on localhost, for the reasons in failure 3. Second, anything that depends on a live backend (logins, search, checkout, personalised content) cannot work offline in any copy, because the server that answered those requests is not in the zip.

A quick decision guide

Whatever you use, keep downloads for your own use. Republishing someone else’s site is a different matter, covered in is it legal to copy a website design?

FAQ