Website backup for offline snapshots
Keep a dated copy of the public pages you may need to read again after a redesign, a content change or a hosting move. A static website backup preserves captured front-end files, not the entire application. Download the archive, inspect its report and keep it in storage you control rather than relying on an account history as your only backup.
Create a website backup snapshot
Download reachable HTML and assets within your plan’s page and depth limits.
Start free — 2 copies a month
Copy only sites you own or have permission to archive. See permissions.
Know what your snapshot protects
Build a repeatable backup habit
Define what website backup means for your site
A useful backup plan starts with a recovery question. Do you need to read old public articles, preserve the appearance of a campaign, recover a published document or restart an entire online service? A static snapshot can support the first group of tasks, but it cannot recreate a database-driven application. Write down the intended recovery outcome and identify which files and systems it requires. This prevents a convenient ZIP from being mistaken for coverage it does not provide.
List the important public sections, language versions and assets before capturing. Include pages that are not obvious from the homepage and check whether they are actually reachable through the selected navigation scope. Keep any native CMS export, database dump and server-file backup in a separate, appropriate process. A front-end archive complements those backups by showing what visitors could see; it does not replace their records, configuration or restore tooling. Private and login-protected content is outside this capture workflow.
Schedule it yourself: no built-in scheduler
There is no recurring scheduler in this product. Each snapshot starts with a capture you submit; opening an account does not begin background backups. Use a calendar reminder, a team checklist or a release procedure you maintain yourself. Decide how often to run it based on how often the public content changes and how much history you can afford to lose. A frequently updated publication needs a different routine from a small site that changes only a few times a year.
Add a manual snapshot before a redesign, a provider change or a significant content removal, then check the result before making the change. Assign someone to review the report and download the files, not merely to press the capture button. Keep planned attempts within your monthly allowance and allow room for tests or corrections. An external reminder is only a reminder: it does not verify completion, renew an expired download or make the service responsible for an unattended backup schedule.
Capture a consistent, documented scope
For repeat snapshots, record the entry URL, selected mode and intended scope so that later versions are comparable. HTTP collects server-delivered HTML and resources without browser rendering. JS-rendered mode saves the browser's observed DOM as static HTML, with page scripts removed and no API replay. If a source changes how it renders, the same mode may produce a different result. Recheck a representative page after major releases rather than assuming a previously successful configuration will always be suitable.
A multi-page capture is not a transactionally consistent backup. Pages are collected over time, and the source may change while the job runs. For your own site, consider a quiet publishing period if cross-page consistency matters. Dynamic timestamps, feeds and late-loading elements can differ between snapshots. Do not rely on a captured checkout, form or account screen as evidence of saved transactions. Those records belong in their original systems and need their own backup and verification procedures.
Treat the report as part of the backup
Keep report.json with the archive so that its limitations remain visible after the original site changes. Review missing, failed and skipped resources and any page, time or size budget indication. Check whether issue lists are truncated; a bounded list is not a complete inventory of every problem. Compare the saved-page list and exported route information with your own list of required URLs. A large ZIP or a high file count does not prove that a particular important page was captured.
A partial result may still be useful as a clearly labelled reference if it has a ZIP that passes the delivery policy. It should not silently replace your last known good archive. Failed and cancelled jobs provide no ZIP, and missing content is not reconstructed automatically. If coverage is insufficient, adjust the scope or choose the other supported mode where appropriate. Document the reason for another attempt and inspect the new result before marking the backup task as complete.
Download within the retention window, then keep your own copies
Available ZIP downloads are retained for 30 days after completion, subject to delivery and entitlement checks. Download important snapshots promptly rather than waiting until the final day. Expired or deleted captures cannot be downloaded through the app. This is a download-access window, not a promise of permanent cloud storage or simultaneous deletion of every operational record. Your long-term backup plan should depend on the files you have actually saved, not on a link in the capture history.
Use a naming convention that includes the site and capture date, and keep a small inventory of scope, mode and known gaps. Preserve the original ZIP unchanged; extract a separate copy when you need to inspect or edit it. Keep another copy in a different storage location so one device failure does not erase the only archive. Apply access controls and encryption appropriate to your organization, and periodically check file integrity and extraction rather than assuming stored files remain readable indefinitely.
Practise reading and recovering from a snapshot
Test recovery before an incident. Extract the entire ZIP while retaining its folder structure and identify the entry page from the saved routes or manifest. Open representative pages and check images, fonts, navigation and downloadable documents. Disconnect the network or use an isolated local environment to find dependencies that still call the original site. The in-app preview is deliberately restricted and is not a substitute for testing the actual files you plan to keep or publish.
If you later publish a snapshot on a static host, configure its routes and redirects and replace backend-dependent features first. Forms, search, accounts and checkout are not restored just because their visual markup exists. HTTP archives may contain untrusted scripts and external calls; inspect them before opening or hosting the files. If the recovery goal is to restore CMS editing, customer records or server behavior, use your separate native backups. Keep the static archive as a complementary reference, with its date and limitations attached.
Choose a scope that fits your plan
Free: $0 — 2 copies/month, 1 page each, depth 0. PRO: $19.90/month or $99/year — 50 copies/month, up to 200 pages, depth 5. Unlimited: $29.90/month or $149/year — no plan copy, page or depth cap; safety caps apply. All prices are in USD.
Free gives you real files, not just a preview. Monthly quotas reset each UTC calendar month, including on yearly plans.
Unlimited means no plan quota for copies, pages or depth, not an unlimited job. Default safety limits are 1000 pages, depth 20, 200 MiB and up to 24 hours per capture, with 1 active job per account. Server limits may be lower; the capture form shows your effective limits.
Download access is available for 30 days after completion, subject to the delivery result. Download important files promptly. Missing resources and partial captures are reported, not hidden.
Frequently asked questions.
General
It is a static snapshot of captured public pages and available assets, not a complete system backup. It does not include databases, server files, CMS administration, private uploads or login-protected content. Use native hosting and database backups as well if you need to restore the application itself.
You can inspect and upload the static files to a suitable host, then configure routes, redirects and replacement services. This does not restore a CMS, database or backend. Test the extracted files and their offline dependencies before relying on the archive for recovery.
Capturing
No built-in scheduler is available. Submit each capture yourself and use an external calendar or team checklist to remind you. Review the report and save the ZIP after each run; a reminder alone does not confirm that a usable backup exists.
Privacy & permissions
Eligible ZIP downloads are available for 30 days after completion, subject to delivery and entitlement checks. Download them promptly and keep your own long-term copies. Expired or deleted captures cannot be downloaded through the app; the account history is not permanent archive storage.
It depends on your rights and intended use. You can archive your own site or a client's site with authorization. A public page is not automatically free to copy or republish; personal backups must still comply with terms, copyright and applicable law. A capture grants no new rights. See the permissions page linked in the hero and footer for guidance and rights-concern reporting; this is not legal advice.