You have searched every settings menu, read the help center twice, and emailed support. The answer is clear: this app has no export feature. Your data is in there — years of it — and the company has built no door. This is the moment most people give up. Do not. There is an escalation ladder for exactly this situation, and it works more often than you would expect.
This guide walks the full ladder: per-item downloads, formal data requests, manual capture techniques, and community tools — plus how to document everything so a complaint, if it comes to that, lands hard. It is the companion to our backup discipline in The 3-2-1 Backup Rule, Adapted for App Users and worth reading alongside our subscription audit in How to Audit Your Subscriptions in Under an Hour, since apps with no export often have billing worth scrutinizing too.
Level one: per-item downloads
No bulk export does not mean no exit. Almost every app lets you open individual items — and what opens can usually be saved. Work through your library systematically: download files one by one, save images, copy text into documents. It is tedious, and for a large library it can take days, but it is thorough and it starts working immediately.
Be strategic about order. Start with the irreplaceable — the originals, the things you created — and work down to the regenerable. If the app paginates your content, work oldest-first; oldest content is most at risk of silent deletion and least likely to be cached anywhere. Keep a simple checklist so you can track progress across sessions without losing your place.
Browser tools can accelerate the tedium. Your browser’s “save page” function captures web-app views complete with formatting; print-to-PDF turns any screen into an archivable document. These are blunt instruments, but for text-heavy content they are surprisingly effective — and they work even when the app offers nothing at all.
Level two: the formal data request
Data-protection laws in many regions — including the EU, UK, California, and a growing list of US states — give you the right to request a copy of your personal data, regardless of whether the app built a self-service button. Find the company’s privacy contact (usually in the privacy policy, sometimes a dedicated email like privacy@) and send a written request: identify yourself, state that you are requesting a copy of your personal data, and specify the categories you want.
Keep the request simple and factual. You do not need to cite statutes, though mentioning your region helps route it correctly. What matters is the paper trail: send it from an email address you control, keep the sent copy, and note the date. Companies typically have around a month to respond, though the exact window varies by jurisdiction.
If the company ignores you, follow up once, then escalate to your region’s data-protection authority. Regulators take ignored access requests seriously, and a documented history of your attempts — the missing export button, the support email, the formal request — makes your complaint concrete instead of vague. Most people never reach this step; everyone benefits from knowing it exists.
Level three: manual capture done right
When automation fails, capture manually — but do it systematically so the result is actually usable. Screenshots work for settings, configurations, and visual layouts: capture full pages, not fragments, and name files descriptively as you go. Copy-paste works for text: paste into documents organized to mirror the app’s structure, preserving headings and order.
For anything interactive — dashboards, timelines, linked content — screen recordings capture what static screenshots cannot. Narrate as you record: “this is my project dashboard, these are the active projects, this is where the settings live.” Future you will not remember the context; the narration preserves it.
Manual capture is also where you document what the app never let you export: your settings and preferences, your sharing configurations, your notification rules, your integrations. Screenshot every settings page. These are the details that make a new app feel like home, and they are the first things forgotten in a rushed migration.
Level four: community tools and unofficial paths
Popular apps with poor exports often have user communities that built what the company would not: browser extensions that scrape your data into files, scripts that call the app’s own APIs, converters that turn proprietary formats into standard ones. Search the app’s name plus “export tool,” “backup script,” or “data download” and see what the community has produced.
Treat unofficial tools with appropriate caution. Prefer open-source tools with visible code and active maintenance over random executables. Never enter your password into a tool you do not trust — prefer tools that work with exported files or official API tokens over ones asking for credentials. And verify the output the same way you would any export: open it, spot-check it, confirm it is complete.
API access deserves a special mention. Some apps with no user-facing export still expose a developer API that returns your data in structured form. Using it may require modest technical comfort, but the app’s own API documentation — or community guides written for exactly this purpose — can walk you through it. Your data, after all, is already structured on their servers; the API just lets you ask for it directly.
Document everything you tried
Throughout this process, keep a log: dates, what you attempted, what worked, what failed, who you contacted. This log serves three purposes. Practically, it keeps a multi-week effort organized. Evidentially, it supports any regulatory complaint. And strategically, it tells the next person — a friend, a forum, future you — exactly which paths are open for this particular app.
Consider publishing your findings. A short post describing an app’s export situation — what works, what does not, what you did — helps every other user of that app and creates public pressure for better export tooling. Companies respond to documented, specific criticism far more than to vague complaints. Your log, cleaned up, is that criticism.
Preventing the next lock-in
Every painful extraction is a lesson about the next signup. Before adopting any new app for important data, run the export test on day one: create a test item, export it, confirm the format is usable. If the app fails the test, you have learned something valuable before investing years of data. An app that cannot export on day one will not magically learn how by year three.
Build this into your adoption criteria alongside price and features: export quality is a feature, and its absence is a cost — just one you pay later, all at once, under stress. The apps worth your long-term data are the ones that let you leave. Everything else is a rental with an uncertain end date.
When the export exists but is deliberately limited
There is a middle ground worth recognizing: the app offers an export, but it is conspicuously incomplete — your files download while your metadata, sharing history, and settings do not. This is rarely an accident; limited exports are often a retention strategy wearing a compliance costume. Treat a partial export as a starting point and supplement it with the manual capture techniques above: screenshot the settings, document the sharing structure, and note what the official tool omitted.
Compare the partial export against your inventory from the preparedness checklist. Every gap between “what I have” and “what exported” becomes a manual task, and prioritizing those gaps by pain score keeps the work focused. The goal is a complete picture assembled from multiple methods — no single method needs to be perfect if the combination covers everything.
Frequently asked questions
Is it legal to scrape my own data from an app?
Accessing your own account through normal means — viewing your own pages, saving your own files — is uncontroversial. Automated scraping sits in a grayer area governed by the app’s terms of service and local law. Prefer official exports, manual capture, and documented requests first; treat aggressive automation as a last resort and understand the terms you agreed to.
Support told me export “isn’t available.” Now what?
That answer refers to the self-service tool, not to your rights. Proceed to the formal data request described above — support teams often do not know about privacy-request processes, which are handled separately. The written request to the privacy contact is the step that carries legal weight.
Are screenshots good enough as a backup?
For visual reference and settings documentation, yes. For data you need to reuse — text to edit, numbers to analyze, photos at full quality — screenshots are a degraded fallback, not a real backup. Use them for what they are good at and pursue better methods for the rest.
How long does a manual extraction take?
It scales with your library. A few dozen items: an evening. Hundreds: a week of spare hours. Thousands: consider whether the formal data request or a community tool can do the heavy lifting. Start with the most valuable items so that even a partial effort protects what matters most.
How do I check a new app’s export before committing?
Sign up, add representative test data — a note with an attachment, a few structured entries — then try every export path the same day. If the app passes, proceed with confidence. If it fails, you have spent an hour to save yourself a future extraction ordeal. Make this your standard for anything that will hold important data.
No export button is an obstacle, not a verdict. Work the ladder — per-item downloads, formal request, manual capture, community tools — document as you go, and convert the experience into stricter standards for the next app. Your data is yours. Sometimes you just have to insist on it.