Download JavaScript Website Offline: Why Copies Go Blank

A copy of a React, Vue or Angular site usually comes out blank because the server sends an almost empty HTML file, and the visitor's browser builds the text afterwards with JavaScript. HTTrack, wget and online downloaders save what the server sends, not what the browser builds, so they save the empty shell. Before you try to download JavaScript website offline, open the page source and search for a sentence you can see on screen. If it is there, a normal crawler can copy the site. If it isn't, you need one of the workarounds below.

Why does a downloaded JavaScript website show an empty page?

A traditional website, such as WordPress, most site builders or a hand-made static site, sends finished HTML: headings, paragraphs, images and links are all in the file. A client-side single-page app (SPA) sends something closer to this: a <div id="root"></div>, a few <script src="/assets/main.js"> tags and very little else. Once the page loads, the script asks an API for the content and inserts it into the page.

When a crawler saves a page like that, three things go wrong:

• The text was never in the file. Crawlers download files; they don't run the scripts inside them. There is nothing to save except the shell.
• Subpages are invisible. SPA menus are often built by JavaScript or use click handlers instead of ordinary <a href> links. Without links in the HTML, the crawler finds only the start page. That is why a website copy often shows only an empty page, and only one of them.
• The app fails offline. Even when main.js is saved, the copy opened from your disk tries to call the live API, expects to be served from the site's root, or meets a router that doesn't recognise a file:// path. The result is a white page or a loading spinner that never stops.

This is a different problem from a copy that has its text but a broken layout. If your pages show content but no styling or pictures, see Downloaded Website Missing Images and CSS? How to Fix It instead.

How do I tell if a website is a single-page app before downloading it?

You don't need developer tools or knowledge of frameworks. The view-source test takes about 30 seconds:

1. Open the page normally and pick a distinctive sentence from the main content. Avoid the menu and footer, because those are sometimes part of the shell.
2. Open the page source. Press Ctrl+U on Windows, Linux or a Chromebook. On a Mac, press Cmd+Option+U in Chrome or Cmd+U in Firefox. In Chrome, Edge and Firefox you can also type view-source: in front of the address.
3. Press Ctrl+F (or Cmd+F) and search for your sentence.

Then read the result:

• Found as normal text in the HTML: the server delivers the content, and any crawler can copy it.
• Not found, and the source is short with mostly script tags and an empty root or app div: the page is rendered client-side. A crawler will save the shell.
• Found only inside a long block of JSON within a <script> tag: the data is shipped, but JavaScript has to turn it into a page. For offline viewing, treat this as a fail.

Two more checks are worth the extra minute. First, repeat the test on a deep page, such as a blog post, product or help article, and not just the home page. Many sites render the landing page on the server and everything else in the browser, or the other way round. Second, search the source for href=" followed by the path of a subpage you know exists. If the menu links aren't in the source, a crawler can't discover the rest of the site, even when the first page has text.

One trap: do not use Inspect or the Elements panel of the developer tools. They show the page after JavaScript has run, so every site looks complete there. Disabling JavaScript for the site in your browser settings and reloading the page gives a similar answer to view-source: if it goes blank, it's client-side rendered.

Client-side vs server-rendered: React, Next.js, Vue, Nuxt and Angular in plain terms

There are three ways a page can get its content:

• Client-side rendering (CSR): the browser builds the page with JavaScript after it loads.
• Server-side rendering (SSR): the server builds the finished HTML for each request.
• Static generation (SSG): the HTML is built once, ahead of time, and uploaded as files.

To a crawler, SSR and SSG pages look exactly like an old-fashioned website, so they copy well. Only CSR causes blank copies. The framework name gives you a hint about which you're dealing with:

The table says "usually" for a reason. Developers can switch any of these setups. A Next.js site can make whole sections client-only, and an Angular team can add server rendering. Treat the framework as a clue and the view-source test as the answer. So if you want to download a React website, the real question isn't "is it React?" but "is the text in the source?"

Server-rendered pages still load JavaScript, which takes over the page once it arrives (developers call this hydration). In an offline copy those scripts may try to fetch fresh data and fail. The text already in the HTML normally stays readable; interactive widgets simply stop responding.

Download JavaScript website offline: what HTTrack, wget and online tools can copy

Neither wget nor HTTrack contains a JavaScript engine. wget downloads files and follows the links it finds in HTML and CSS. HTTrack does the same, and it also scans scripts for strings that look like URLs. That sometimes picks up an extra file, but it never runs the code. So there is no setting that fixes the HTTrack blank page problem on JavaScript sites. wget can't produce a JavaScript-rendered page either: --mirror, --page-requisites and --convert-links fix missing assets and links, not missing content. For a broader comparison of the two tools, see wget vs HTTrack vs Online Website Downloader.

Online downloaders fetch pages the same way, and Website Downloader is no exception. Sites that build their content entirely in the browser can produce an archive that contains the page shell but not the content. Pages behind a login are not downloaded. When a site refuses automated downloads, for example with a 403 response, the service reports that instead of handing you an empty archive.

Where it does help is the large group of sites that pass the test: server-rendered Next.js and Nuxt sites, static sites and conventional CMS sites. Enter the address on the home page, and the service downloads every subpage with its images, stylesheets, scripts, fonts and media into one ZIP file that opens offline in any browser. It runs in the browser, so there's nothing to install. The free plan covers up to 100 subpages without an account, which lets you confirm on a real copy that the content came through before you pay for anything bigger (see pricing). The full workflow is in Download a Website as ZIP Online.

How do I save a page after its JavaScript has finished loading?

If the site fails the test, crawling it again with different settings won't help. Pick a route based on how many pages you need and what you need them for.

Check the other parts of the site first

A blog, documentation area or help centre often runs on a separate system, such as WordPress, Ghost or a static generator, even when the main product is a single-page app. Run the view-source test on each section, and crawl the sections that pass. A blog's RSS feed can also contain the full text of recent posts.

Save individual rendered pages from your browser

For a handful of pages, your browser is the simplest tool, because it saves what it has already rendered. In Chrome and Edge, use Save page as and choose Webpage, Complete or Webpage, Single File. Firefox has a similar option. Print to PDF is the most robust choice for reading or evidence. The SingleFile browser extension saves the rendered page as one self-contained HTML file. One caveat: if saved scripts run again when you open the file, they can wipe the content. If that happens, use PDF or a save option that removes scripts. Each page is saved on its own, and links between them still point to the live site. The step-by-step guides for Chrome and Firefox cover the details. If the copy is meant as proof, read Archive a Website for Legal Evidence.

Use a headless browser for many pages

A headless browser is a real browser without a window: it runs the JavaScript and can hand you the result. Chrome can do this from the command line: chrome --headless --dump-dom https://example.com/page > page.html. The program name varies by system: google-chrome or chromium on Linux, or the full path to Chrome on Windows and macOS. This gives you the rendered HTML of one page, but images and links still point online.

To cover a whole site, developers write a short Puppeteer or Playwright script. It reads the URLs from the site's sitemap.xml, opens each one, waits until network activity stops, then saves the HTML and a screenshot. For high-fidelity archives, Webrecorder's tools (ArchiveWeb.page and Browsertrix Crawler) record browsing sessions as WARC files, which you replay in a viewer rather than open as plain HTML. The trade-offs are real: you need some programming comfort, you fix links and assets yourself, it is slow, and busy sites may rate-limit you.

Check the Wayback Machine

The Internet Archive may already have captured the site. Open a capture and run the same view-source test on it. If the text is in the captured HTML, the Wayback Machine downloader can turn that capture into a ZIP with the playback toolbar and archive.org links removed. It is free up to 100 pages, or 14.99 EUR one-time for up to 5000. If the capture is also just a shell, a restore won't bring the content back. The full process is in Restore Website from Wayback Machine.

Ask the owner for the source or a static export

If the site belongs to you, a client or your employer, this gives the best result by far. A developer can produce a fully static export from many frameworks: for example, output: 'export' in a Next.js config, or npx nuxi generate for Nuxt. The content itself usually lives in a CMS or database that has its own export. Be aware that the build folder of a client-side app is not an offline copy on its own, because it still calls the live API for its content.

Whatever method you use, only copy what you're entitled to keep. Copyright and website terms differ by country and situation. If you plan to reuse the copy commercially or rely on it in a dispute, ask a lawyer; this article is not legal advice.

What still won't work offline, even when the content downloads

Passing the source test gets you the text, images and layout, but not the server behind them. In any offline copy, whatever tool made it:

• Site search, contact forms, newsletter sign-ups and comments do nothing.
• Shopping carts, checkouts, logins and account areas don't work.
• Live data such as prices, stock levels and feeds is frozen at the moment of download.
• "Load more" buttons, infinite scroll, filters and sorting show only what was in the HTML.
• Embedded maps, videos and social widgets from other services still need an internet connection.

If you need those features to keep working, you need the site's source and a server, not an offline copy. The FAQ covers more questions about what an archive contains.

FAQ: JavaScript sites and offline copies

Why does my HTTrack or wget copy of a website show a blank page?

The site builds its content in the browser with JavaScript, and neither HTTrack nor wget runs JavaScript. They saved the HTML shell the server sent, and the app inside it can't load its data from your disk. Run the view-source test: if your sentence isn't in the source, no crawler setting will fix it.

Can I download a React, Vue or Angular website with all its content?

Yes, if the pages are rendered on the server or generated as static files, which is common with Next.js, Nuxt and Angular with SSR. A plain client-side app can't be crawled into a working copy. You can still save its pages one by one from your browser, capture them with a headless browser, or get a static export from the owner.

Does a site built with Next.js or Nuxt download better than a plain React app?

Usually, yes. Both frameworks normally send finished HTML, so crawlers see the same text you do. Some sections may still be client-only, so test a few deep pages rather than trusting the framework name.

Is a headless browser worth it for archiving a JavaScript site?

For a few pages, saving from your normal browser or printing to PDF is faster. For dozens or hundreds of client-rendered pages, a Puppeteer, Playwright or Webrecorder setup is the only reliable route, but expect to spend time on scripting and fixing links. If the site passes the source test, skip the headless browser and use an ordinary crawler instead.