Guides
What We Log, and What We Do Not
Short version: no video links, no IP addresses, no files. The link you paste is stored as a one-way hash and never as text. The visitor identifier is a hash of address and browser that changes when either does. Downloaded files are streamed through and never written to our disk. Below is every field we actually record and why it exists.
Every field we write, in full
| Field | Example | Why it exists |
|---|---|---|
| Timestamp | 2026-08-01T14:22Z | Ordering events |
| Event type | download_ok, extract_failed | What happened |
| Link hash | a3f2f9605acb5fe3 | Spotting one broken video vs many |
| Platform | youtube, tiktok | Which sites people bring |
| Quality | 720 | What gets chosen |
| Visitor hash | 7c41be09ad2f | Free quota; first-attempt outcome |
| Language | en, es | Which translations matter |
| Short detail | merge_timeout | Diagnosing failures |
That is the complete list. No account, no email for free use, no address, no device fingerprint, and no readable link.
Why the link is a hash and not text
The address you paste is the most sensitive thing you hand any downloader. It says what you watch, and taken together over time it says a great deal more than that.
We run it through SHA-256 and keep the first sixteen characters. That is a one-way operation: the same link always produces the same hash, and no one can work backwards from the hash to the link. Not us, not anyone who obtains the file.
The hash is still useful for the one thing it needs to do. If forty failures share a hash, one video is broken. If forty failures have forty different hashes, something in the service is wrong. That is the entire purpose, and it works without the original text.
Storing links in the clear would be easier and would answer more questions. It would also create a file that is a liability the moment it exists — and no promise about handling it carefully is as good as not having it.
Why the visitor identifier is not an identity
Some identifier is unavoidable if a free tier has a daily limit. Without one, a limit is not a limit.
Ours is a hash of the network address and the browser string, sixteen characters. The raw address is never written anywhere. Change network and you become a different visitor; update your browser and the same happens. It is deliberately weak as an identifier and strong enough for a daily counter.
It answers one product question that nothing else can: what happened on someone's first attempt. That matters more than it sounds — a service can look healthy in aggregate while failing most newcomers on their first try, and without a way to group one person's attempts that pattern is invisible.
What it cannot do is follow you between networks, tie sessions together over time, or connect to anything you do elsewhere. There is no cookie for this, and no third-party tracker involved.
Files: streamed, never stored
The video itself is the largest privacy question and has the simplest answer.
For qualities we assemble, the file exists briefly in a temporary folder while it is built, is sent to you, and is deleted. For everything else the data passes through in 64 KB chunks and is never written to disk at all.
Nothing accumulates. There is no library of downloaded videos, no cache keyed to popular links, and no copy retained for performance. If you asked us tomorrow what you downloaded today, we could not tell you, and that is by design rather than by policy.
Caching would be the obvious optimisation and we do not do it. A popular video fetched a hundred times is fetched a hundred times, which costs us bandwidth every single time. The alternative is a store of files keyed to what people asked for — which is a library of requests wearing a different name, and it would sit on a disk for as long as it was useful.
The same reasoning rules out a download history feature, which people occasionally ask for. Showing you what you saved last week requires keeping a record of what you saved last week, tied to something that identifies you. It is a genuinely useful feature and it is incompatible with the rest of this page, so it does not exist.
What paid accounts add, and only paid accounts
Paying requires more, and the boundary is worth stating precisely.
- Email address. To send the licence key and expiry reminders. Free use never asks for one.
- Password hash. Stored via scrypt — the password itself is never written.
- Licence record. Plan, dates, whether it is active.
- Payment reference. From the payment provider, so a payment can be matched to a licence.
What a paid account still does not add is any link to what you downloaded. The licence system and the event log share no identifier, deliberately — knowing that a licence is active and knowing what someone saved are two different questions, and we can only answer the first.
What we could collect and chose not to
The interesting part of any privacy position is not what is absent because it was never needed — it is what was available, useful, and left alone.
Referrer. Browsers will tell a site which page you arrived from, and it is genuinely valuable for understanding where visitors come from. On a downloader it is also occasionally the video page itself, which would put back in the log exactly what hashing the link takes out.
A durable cookie. A stable identifier would make the free quota harder to reset and would let us follow a person across sessions. The quota works acceptably on a hash that changes with the network, and the cost of the stronger version is a genuine identity where none existed.
Third-party analytics. A single line of script would answer far more product questions than our own logs do. It would also hand every page view to a company with its own interests, on a site where the page view is the sensitive part.
Device fingerprinting. Screen size, fonts, timezone and hardware combine into an identifier that survives network changes and private windows. It is effective, it is invisible to the person being measured, and it is precisely the technique someone using a browser tool instead of an app is trying to avoid.
Each of those would have made the product easier to run. None of them would have made a single download work better, which is the test we applied.
How to judge any downloader's privacy claims
Useful regardless of which tool you use, because the claim is easy to make and rarely checked.
- Does it require an account for basic use? If yes, everything you do is tied to an identity by construction.
- How many trackers load on the page? Open the browser's network view. Third-party analytics and ad scripts see the page you are on, whatever the site's own policy says.
- Does the privacy policy name specific fields? ‘We respect your privacy’ is not a statement about data. A list of what is stored is.
- Does it explain retention? ‘As long as necessary’ means indefinitely.
- Is it an app or an extension? Both hold permissions far beyond the task — more on that trade-off.
Point two catches more than the rest combined. A page with a warm privacy policy and nine advertising trackers has answered the question in a way the text does not.
The log we switched off, and the one we had to add
Two changes made on 1 August 2026 explain our position better than any policy statement, because both cost us something.
The first was turning off the web server's standard access log. It writes a line per request containing the full request — and on this service the request line carries the video address as a parameter. Every link anyone submitted was being written to a file in readable form, by a default nobody had chosen. It was not being used for anything and it contradicted what we said about links. So it is off, and our own access log records the path without the query string.
That is a real loss. Standard access logs are how you debug a web service, and running without one is harder. It seemed the wrong trade to keep a file of everyone's links for the convenience of occasional debugging.
The second change went the other way. For a long time the event log recorded only failures, which made it useless for the questions that matter: how many people reach a finished download, which platforms they bring, where the free tier stops them. Ten failures is meaningless without knowing whether there were twenty attempts or two thousand. So successes are logged now too — same fields, same hashed link, no new personal data. More records, not more knowledge about anyone.
The shape of both decisions is the same. The question is never whether logging is good, it is which specific field earns its place. A raw link earns nothing that a hash does not, so the raw link goes. A success event earns something no failure event can provide, so it stays. Applied field by field, that reasoning produces the table at the top of this article — and it is a table we can publish precisely because there is nothing in it we would rather you did not know.
One honest limitation. Our traffic passes through a content delivery network, as almost every site's does, and that provider sees connections in order to route them. We do not control what any intermediate network keeps. What we can say is what reaches us and what we write down, which is what this article documents.
Frequently asked questions
Do you store the links I paste?
No. Each link is hashed with SHA-256 and only the hash is stored. The original text is never written and cannot be recovered from the hash.
Do you log IP addresses?
No. A hash of address and browser is used for the daily free limit; the raw address is never written to any file.
Are downloaded files kept on your servers?
No. Assembled files are deleted immediately after sending, and everything else is streamed through without touching the disk.
Do I need an account?
Not for free use. An email address is only required for a paid licence, so the key and expiry reminders can be sent.
Can you tell what I downloaded?
No. We can see that a download of a given platform and quality succeeded, and a hash we cannot reverse. The licence system shares no identifier with the event log.
How do I judge another downloader's privacy?
Check whether it requires an account, count the third-party trackers on the page, and see whether the policy names specific fields rather than making general promises.
VidKeep runs in your browser — paste a link, pick a quality, keep the file. No account, no app.
Open VidKeepLast updated: 2026-08-01. We revise our guides as the platforms change.
