How to Download a Website from Archive.org: 3 Ways That Work

The site is gone. The hosting lapsed, the client never kept a backup, and the only copy left sits on the Wayback Machine. I have had that exact phone call more times than I can count, and the first question is always the same: can you download a website from archive.org and get it back?

Yes, you can. There are three realistic routes: saving pages by hand, scripting against the CDX index, or letting an automated restore service do the crawling for you. They differ wildly in effort, and the wrong choice costs you a weekend. Here is how each one actually works, with honest time estimates from doing this for a living.

What downloading from the Wayback Machine really means

The Wayback Machine is not a folder of websites you can grab with one click. It is a giant index of individual captures: every page, image, stylesheet and script stored separately, each tied to the moment it was crawled. When you view an old page, your browser pulls the HTML from one capture and the images from several others, stitched together on the fly.

So downloading a site means enumerating hundreds or thousands of individual files, fetching each one, and rewriting the internal links so the copy works outside archive.org. Keep that model in mind, it explains why every method below works the way it does, and why none of them is a single download button.

Method 1: download a website from archive.org page by hand

The naive approach, and sometimes the right one. You open the snapshot in the Wayback Machine and save each page with your browser. For a five-page brochure site, this is honestly fine. For anything bigger, it is a slow form of punishment.

1. Open the archived page at the snapshot date you want.
2. Use Save As and pick 'Web Page, Complete' so assets come along.
3. Repeat for every page, including the ones only reachable from old menus.
4. Open the saved HTML and strip the Wayback toolbar markup from each file.
5. Fix or accept the asset URLs, which still point back at web.archive.org.

Two traps wait here. The saved HTML references web.archive.org for many assets, so your copy breaks the moment you open it offline or the archive has a slow day. And the toolbar markup baked into every saved page has to be picked out by hand, file by file. I still use this method for single pages, a client once needed just their old pricing page for a legal dispute, and one save took two minutes. Their 300-page store got a different treatment.

• Realistic effort: 5-10 minutes per page once you include asset cleanup.
• Good for: up to about 10 pages, or grabbing one specific page for reference.
• Breaks down at: dozens of pages, or any job where you need clean original markup.

Method 2: download a website from archive.org with the CDX API

The CDX API is the Wayback Machine's index endpoint, and it is how you find every file archive.org holds for a domain. One query returns the full ledger as JSON:

web.archive.org/cdx/search/cdx?url=example.com/*&output=json&fl=timestamp,original,mimetype,statuscode&filter=statuscode:200&collapse=digest

That gives you timestamps, original URLs and MIME types for everything captured. The collapse parameter dedupes identical files, so you do not download the same logo 400 times. From there, a small script walks the list and fetches each file. Append id_ to a timestamp URL, like /web/20150312145531id_/http://example.com/style.css, and archive.org returns the original bytes without its rewritten markup. That one suffix is the difference between a clean copy and a page full of toolbar.

The unglamorous parts are what eat your evening. Archive.org throttles aggressive clients, so the script needs polite delays and retry logic, or you will spend hours staring at 429 responses. Query-string URLs need deduping, or session IDs turn a 200-page site into a 9,000-file crawl. And after the files land, internal links still point at the original domain, so you need a rewriting pass before the copy browses properly offline.

• Realistic effort: 2-4 hours to write and debug the script if you code regularly; a weekend if you do not. The crawl itself takes 30-90 minutes for a few hundred files.
• Good for: developers, archivists, anyone who wants full control over every byte.
• Breaks down at: people who have never opened a terminal, and deadlines measured in hours.

Whatever you script, test the result the way a visitor would: serve the folder with any local web server and click around. Broken image paths, links escaping to the live web, and missing fonts all announce themselves within five minutes of clicking, and are miserable to discover after you have declared the job done.

Method 3: download a website from archive.org the automated way

The third route lets a restore service do the crawling, asset matching and link rewriting. This is what I point clients to when the site matters more than the learning experience. With this restore service you paste the domain and get a free instant estimate: exact archived file count, total size, and a locked price before you pay anything. You pick a date range, flip the options you want, and the restored copy lands ready to browse, or deploys straight to your hosting over SSH, FTP, or S3.

• Options worth knowing: relative internal links, stripping old analytics and ads, minifying JS/CSS, HTTPS conversion, www or non-www canonicalization.
• The restore can export a structured manifest (JSON or SQLite) so you know exactly what came back.
• Failed restores refund automatically to your balance, no support tickets.

The catch is obvious: it costs money. You pay per restored file, the first file is free, and the price is locked at estimate time. For a personal blog you might happily script instead. For a client's revenue-generating WooCommerce store that needs to be back tonight, the fee is usually the cheapest line item in the whole incident. Deploys also include a small single-file CMS, so minor text fixes after the restore do not require re-uploading anything.

Time and effort, side by side

Notice the table measures your time, not machine time. A script or a service may chew on a large crawl for hours, but it chews while you sleep. The scarce resource in any restore is the evening of the person doing it, so that is what I price.

Mistakes that burn whole afternoons

• Trusting browser saves for full sites. You will miss every page you did not manually open, and old sites hide pages in places you forgot existed.
• Ignoring the id_ modifier, then wondering why every HTML file has Wayback toolbar markup baked in.
• Hammering archive.org with parallel requests. You get throttled, and a one-hour job becomes four.
• Skipping the link-rewriting pass. The copy looks fine until you click anything.
• Assuming every page was archived. Check the CDX inventory first so gaps are a known quantity, not a surprise at the end.

Which method should you pick?

Under ten pages: save them by hand and accept the markup warts. You write code and want control: build the CDX script and budget an evening. You need the site back, clean, without becoming a part-time archivist: take the automated route, the tutorial walks through a full restore in a few minutes, and the free estimate tells you the file count and price before you commit anything.

One last thing: whichever route you take, take it now. Archive.org is a gift, but it has had outages and legal pressure before, and 'I will grab it later' is exactly how sites get lost twice.