Downloading one webpage is easy. Downloading an entire website is a different job. You need the pages, the CSS, the JavaScript, the fonts, the images, and rewritten references so those files still load after they leave the original host.

That is why a browser "Save page as" folder often looks fine once, then loses style, images, or navigation as soon as you click around. The HTML arrived. The assets did not, or they still point at a CDN you no longer control.

This guide is about how to download an entire website and keep those assets intact. It covers public, client-side sites. It does not cover copying private data, bypassing access controls, or reproducing a service you do not own. Only export sites you control or have permission to archive.

How to keep a full website download from breaking

Do these five things first.

Decide the scope. Capture the homepage plus every public route you still need, including pricing, contact, legal, blog templates, and localized pages.
Capture more than HTML. The ZIP or folder must include CSS, client-side JavaScript, images, icons, web fonts, and public downloads those pages request.
Rewrite references. Local files must point at local files. A leftover https://cdn.example.com/style.css means the copy still borrows from the live site.
Leave only intentional remotes. Maps, videos, analytics, and payment widgets can stay external. A logo, stylesheet, or font should not.
Smoke-test offline. Serve the folder locally, disconnect the network, and click through. Broken CSS, missing fonts, empty srcset images, and JavaScript-only routes show up here.

If you want an offline viewing copy you can open with no live host, see the offline website downloader guide.

If you want a hosted version of that path, Export Your Site is one way to create a public-site copy. Compare methods in the best website downloaders guide if you are still choosing a tool.

What a complete static website download contains

A usable static copy normally includes five groups of files:

HTML documents for the homepage and every route you want to keep.
CSS stylesheets that define typography, spacing, layout, breakpoints, and visual states.
Client-side JavaScript used for navigation, menus, sliders, and other browser interactions.
Assets such as images, icons, video posters, downloadable files, and web fonts.
Rewritten references so those pages and assets point to their new local locations instead of the old host.

The fifth item is the one basic download commands often miss. A browser may request an image from a CDN, a font from a generated asset URL, and a script from a platform domain. If the downloaded HTML still points to those remote addresses, the copy is not independent. It is merely borrowing pieces from the original site.

If those five groups are present and the references are local, you have a site copy. If a required stylesheet, font, or image is still remote, you have a partial save.

Save website as HTML vs download entire website

"Save website as HTML" can mean a few different jobs. The right tool depends on whether you need one page for reference or a multi-page site copy you can test and host.

| Goal | Typical output | What it is good for | Main limitation | | --- | --- | --- | --- | | Save one webpage as HTML in the browser | One .html file plus a nearby asset folder | Receipts, articles, landing-page snapshots, personal reference | Usually does not crawl other routes or rewrite a whole site | | Use SingleFile, Save Page WE, or a similar extension | One self-contained HTML file or a page-level bundle | Cleaner single-page archives and offline reading | Still page-first, not a reliable migration copy of a route graph | | Download an entire website | A folder or ZIP containing pages, assets, and rewritten links | Static archives, migration planning, temporary self-hosting | Requires crawl scope, verification, and replacement plans for dynamic services |

If you only need to save a webpage as HTML, the browser path can be enough. Open the page, use "Save page as," then test the file with the internet disconnected. Extensions can improve that one-page snapshot by inlining assets or collecting more of the page's immediate dependencies.

If you need to download website as HTML across multiple pages, you need a crawler or exporter. It should discover routes, fetch required assets, preserve clean internal navigation, and rewrite references so the copied pages point at each other instead of the original host. That is a different job from a browser save.

For builder sites, start with the builder-specific guides when you know the source platform: Webflow export, Framer export, Wix website download, Squarespace website download, and WordPress to static HTML. The static-copy boundary is similar, but each platform has different CMS, forms, and hosted-feature traps.

Static copy versus original source

An exported public site is the output of a build and publishing process. It is not necessarily the input that created it.

If a site was built in Framer, Webflow, or Wix, the public HTML does not contain the original canvas, component model, CMS setup, or editor history. A static download can preserve what browsers receive. It cannot reconstruct the private project format with perfect fidelity.

If you already know which builder made the site, the supported website exporters give you a platform-specific starting point.

That still makes a static archive useful. You can:

self-host a marketing site or portfolio;
preserve a snapshot before a redesign;
move a mostly static site away from a subscription;
inspect the files for migration planning;
use the visible site as a reference while rebuilding it in another stack.

What you should not expect is a clean, hand-authored component library. Generated sites often contain generated class names, bundled scripts, and optimized assets. The files are still yours, and an AI assistant can help you swap text or add a page.

Three ways to download a website

1. Use the browser for one page

Every major desktop browser can save the current page with its immediate assets. This is useful for a personal snapshot of a receipt, article, or reference page.

It is a weak choice for a site migration because it does not reliably crawl other routes, normalize URLs, or reproduce application navigation. Test the saved file with your internet connection disabled. If it loses styling or images, the snapshot still depends on the original host.

2. Use a command-line or desktop mirror tool

Tools such as wget and HTTrack can crawl links, fetch assets, and rewrite references. They work well when the site serves conventional HTML and has a clear link structure.

A typical wget command might use recursive crawling, page requirements, and link conversion. The exact flags matter, and an unrestricted crawl can consume far more bandwidth than intended. Set a page or depth limit, stay on the domains you control, and review the tool's documentation before running it.

Modern builder sites make this method harder. Important links may appear only after JavaScript runs. Assets may be loaded from several domains. Responsive images can hide behind srcset values, and client-side routing may not expose ordinary links to a basic crawler.

If you are comparing HTTrack with a hosted snapshot, the HTTrack alternative guide explains where desktop mirroring works well and where modern builder sites need a different acceptance test. For a broader category comparison, use the guide to best website downloaders. The website copier tools comparison maps the same job across desktop apps, extensions, and hosted snapshots.

3. Use a hosted snapshot

A hosted exporter fetches the public pages a browser would receive, follows discovered routes, downloads required assets, and packages the result. It is often easier to verify than a local crawl. It still cannot copy private backends.

The useful feature is an inspectable copy. You can test navigation and responsive behavior before you accept the archive. A hosted snapshot follows that order: export first, open the copied site, then keep the ZIP if the copy is useful.

Website to ZIP: what the archive should mean

For a full public-site copy, "website to ZIP" usually means the final package contains the captured static site: HTML documents, CSS, JavaScript, images, fonts, downloads, and rewritten references. You unzip it, inspect the folder, and upload those files to a static host or keep them as an archive.

That is different from "ZIP to hosting" or a reverse deploy flow. A website-to-ZIP tool starts from the live public URL and produces a portable static output. It should not require access to the original builder account, and it should not claim to reconstruct the private CMS database, design canvas, ecommerce backend, or editor project.

A practical static ZIP should answer these questions:

Is there an entry page such as index.html?
Do internal links point to captured pages rather than the old host?
Are CSS, JavaScript, image, font, and downloadable file references local when they need to be?
Are external services still external intentionally, such as maps, videos, analytics, forms, or payments?
Can you open the copy and click through it before deploying the ZIP?

A hosted snapshot keeps that promise narrow: a static mirror of public browser output, not an editable builder project.

The website to ZIP guide goes deeper on archive contents and deploy checks if that is already the format you want.

Why downloaded websites lose CSS, images, and fonts

A broken copy usually fails in a few repeatable ways. The missing file or leftover URL is the problem. The homepage screenshot is not.

The stylesheet never made it into the folder

The HTML may still contain <link rel="stylesheet" href="https://...">. If the exporter did not fetch that CSS, or did not rewrite the href, the page renders as unstyled text.

Open the HTML and find every stylesheet link. Confirm a matching local file exists. Do the same for @import rules inside CSS. One missing imported sheet can drop a whole breakpoint or font stack.

Fonts still load from Google Fonts or a builder CDN

Typography often comes from a second request. Google Fonts, Adobe Fonts, and builder CDNs serve .woff2 files from their own hosts. A copy that keeps those URLs looks fine online and falls apart offline.

Download the font files the CSS actually uses, then rewrite @font-face src values to local paths. If a license forbids hosting the files yourself, use a different font you can host.

Images and scripts still point at a CDN

Builder sites commonly serve images from hashed asset domains. Webflow, Wix, Squarespace, and similar platforms put photos and icons on a CDN hostname that is not your site. Scripts may come from a platform pack. If the HTML still uses those absolute URLs, the page still loads those files from the live site.

Every required image, icon, and script should exist in the archive and be referenced by a relative path. Leave third-party embeds alone when they are meant to stay remote, such as a YouTube iframe.

`srcset` and picture elements hide extra files

Responsive images list several URLs. A crawler that only reads src can miss the 2x file or the mobile WebP. The page then looks sharp on a laptop and empty on a phone, or the other way around.

Capture every URL in srcset and in <source> elements. After the export, resize the window and confirm images still appear at mobile and retina widths.

JavaScript-only routes never become HTML files

Many Framer, Webflow, and similar sites render extra pages through client routing. A crawler that only follows <a href> in the first HTML payload misses those routes. You get a homepage that works and a /pricing URL that 404s.

Inventory routes from the live sitemap, nav, and footer before you export. Confirm each needed path exists as a real HTML file in the copy. If a tool cannot see JavaScript-only links, use an exporter that discovers those routes or add the URLs by hand.

Absolute links send you back to the live site

An href="https://yoursite.com/about" in the copy opens the original host, not about/index.html in the ZIP. A root-relative /about can do the same if you open files from disk without a local server.

Rewrite internal links to relative paths that match the folder layout. Then serve the folder through a local static server instead of double-clicking index.html, so root-relative paths resolve.

Hydration scripts expect the original origin

Some bundles look up the current hostname, a CMS API, or a signed asset URL at runtime. The HTML and CSS may be local while the script immediately refetches live content, or errors out and kills the menu.

Open the browser console on the copied page. A failed request to the old host is a remaining dependency. Replace that feature or accept that it stays live. Do not treat a pretty homepage as proof that JavaScript survived.

How to verify the downloaded copy

Do not judge an export from the homepage screenshot. Use a repeatable check.

Check every important route

Open the homepage, pricing, contact, legal, and at least one deep content page. If your site uses localized routes or a CMS, sample each content template rather than every near-identical item.

Check viewport changes

Resize from desktop to mobile widths. Open navigation menus, accordions, tabs, and overlays. A layout can look correct at one width while missing a responsive stylesheet or script needed at another.

Check internal and external links

Internal links should stay inside the copied site. External links should still point to their intended destinations. Watch for links that return to the original builder-hosted domain, especially in logos, mobile menus, and footer navigation.

Check the network boundary

The strongest test is to serve the files locally, disconnect from the internet, and browse the copy. Some third-party resources are intentionally remote, including analytics, embedded video, maps, and payment widgets. The point is to know exactly which dependencies remain.

Check the console

Open the browser developer tools and look for failed requests or JavaScript errors. A missing decorative image is different from a script error that stops all navigation. Classify failures by effect instead of chasing a perfectly clean console at any cost.

What will not transfer as static files

The following features usually depend on a server, database, or private platform API:

form submissions and email automations;
CMS editing and content workflows;
user accounts, memberships, and gated pages;
ecommerce inventory, carts, checkout, and order history;
bookings, search indexes, comments, and dashboards;
server-side personalization and protected API routes.

The visible form can appear in a copy while its submit action still points to the old platform. That is why visual inspection is not enough. Submit test data before changing DNS, or replace the form action with a provider you control.

A safer migration order

Use this sequence when the download is part of a move:

Inventory the routes and dynamic services on the live site.
Create the static copy without changing the original.
Inspect and test the copied routes.
Replace forms, analytics, search, and other required services.
Deploy the copy to a temporary hostname.
Run mobile, link, accessibility, and performance checks.
Lower DNS time-to-live if necessary, then point the domain to the new host.
Keep the original plan active until the new site has handled real traffic successfully.

This avoids turning an export problem into an outage. The monthly fee for a few overlapping days is usually cheaper than a rushed rollback.

If the next step is cheap static hosting after you have files, use self-host your website.

Choose the output based on the job

If you need a faithful archival snapshot, prioritize complete assets and offline behavior. If you want a framework codebase you maintain in Git, use the static copy as a reference. If you want to self-host the pages and keep changing them, the files are yours and an AI assistant can help after you reconnect forms or other hosted services.

The honest definition is simple: a website download captures what the public browser can receive. It does not magically turn every hosted product into portable source code. Start with an inspectable copy, check the boundary, and decide whether the result fits the job.

FAQ

How do I download an entire website?

Start from a public URL you own. Use a crawler or exporter that discovers routes, downloads HTML, CSS, JavaScript, images, and fonts, then rewrites those references so they point at local files. Inspect the copy, then keep the folder or ZIP only if important pages still render with the network off.

Can I save a website as HTML?

You can save a single webpage as HTML from most desktop browsers, and extensions such as SingleFile or Save Page WE can make that one-page archive more self-contained. Saving an entire website as HTML is a bigger crawl-and-rewrite job. For a multi-page site, use a mirror tool or exporter that captures routes, assets, and internal links, then test the result before relying on it.

How do I download a website as a ZIP?

Use a website downloader that starts from a public URL you own, captures the reachable pages and assets, rewrites references, and packages the output as a static ZIP. The safest flow is inspect first: click through the copied site, check mobile navigation and important pages, then keep the ZIP only if the copy passes. The website to ZIP guide covers that archive format in more detail.

Why does a downloaded website lose its CSS or images?

The usual cause is a reference that was never rewritten. The HTML still points at a CDN stylesheet, a builder image host, a Google Font, or a srcset URL the crawler skipped. Open the copied page with the network off. Whatever 404s in the Network panel is the missing file. Fetch it, rewrite the path, or accept that it is an intentional remote embed.

Why does Save as HTML break when I click around?

Browser "Save page as" is page-first. It usually saves the current document and nearby assets, but it does not reliably crawl every linked route, discover JavaScript-only navigation, or rewrite the whole site's internal links. When you click around, the saved page may try to open files that were never captured or may jump back to the original website.

Can I download a whole website as files?

Yes, if you mean the public pages a browser can receive. A complete website download and a full website download are the same job. You choose the routes, capture their required assets, rewrite links, and test the result. The ZIP will not include the CMS, editor, checkout, or private APIs behind those pages.

There is a website export page for copying published pages.