Privacy.Read off the code.
This is not a policy written to be survivable in court and unreadable everywhere else. It is a list of the fields we store, the one place your content goes, and the day each thing is deleted. Where the honest answer is uncomfortable, it is on the page anyway.
Last updated 2026-07-24· draft, not lawyer-reviewed
Eleven things,and that is the list.
Every item below is a column in the database or a file on disk. Nothing is collected that is not used to run a job, bill it, or let you sign back in.
Your email
Lowercased and used as the account identifier. It is how you sign in and the only way we can reach you.
Your name
Whatever you typed at signup, capped at 80 characters. It names your first project. Nothing checks that it is real.
A password hash
scrypt with a per-account random salt, stored as salt and derived key. The password itself is never written down, never logged, and cannot be recovered from what we hold.
Session records
One row per signed-in browser: a sha256 of the cookie value, the account it belongs to, and an expiry. The raw token only ever exists in your browser.
The footage you give us
A file you upload, or a URL we fetch on your behalf. Uploads are stored under a random key until the render is finished.
What comes out of it
Clip videos, poster frames and SRT files, plus the metadata that makes the editor work: word-level timings, the score and its five axes, what the model saw, heard and read on screen, the title, and the post caption.
Job records
The source you gave, the options you set, any timestamps you pasted, your callback URL and passthrough metadata, status, progress, error text, and the timings of every attempt.
A credit ledger
Append-only. Every hold, settle, refund, grant and top-up, with the job that caused it. This is the billing record, so it is deliberately not editable.
Storage used
A running byte count per account, checked against the 100 GB allowance before an upload is admitted.
Your brand kit
Accent colour, default caption style, default post voice, and a logo file with its position, scale and opacity.
A Google account id
Only if you sign in with Google. It is Google's permanent identifier for your account - a number, not a token, and it grants us nothing - stored so a later sign-in finds the same account even if you change the address on it. We ask Google for your email, its verified flag and your name. Nothing else.
There is no payment processor wired into the product. Plans are arranged over email, which means we have never had your card number and cannot lose it.
What actuallyleaves the machine.
A clipping tool that reads pictures has to send something somewhere. Here is precisely what, and precisely to whom.
The model provider
Anthropic. It does the detection, the multimodal review, the titles and the post captions. It is the one place your content leaves our infrastructure.
Frames, not the file
The video itself is never uploaded to a model. What goes out is JPEG stills, each scaled to fit inside 512 pixels: three per candidate at review, and on footage with no usable dialogue a sweep of up to 32 stills across the stretch being processed, because there the pictures are the only signal.
Not the audio
The soundtrack never leaves. Four measurements per window - loudness, brightness, transient, flatness - are reduced on the worker to one plain sentence, along the lines of loud and broadband, consistent with crowd noise. That sentence is what the model reads.
Transcripts run here
Speech-to-text runs on our own worker, not at a transcription vendor. Excerpts of the resulting transcript are sent with the frames, because that is what the model scores.
Fonts are served by us
All three typefaces are built into the deployment. Your browser never makes a request to a font CDN, which is a tracking vector wearing a typeface.
Storage is an object bucket
Uploads and rendered artifacts are written to an S3-compatible bucket rather than to a disk we own - on the hosted service that is Cloudflare R2. Your browser and our worker read and write it directly over short-lived signed URLs, so the bytes do not pass through the app, but they do sit with that provider until the retention sweep below deletes them.
Google, only if you use it
Choosing 'Continue with Google' sends your browser to Google to sign in, exactly as visiting Google would; we then trade the resulting code with Google's token endpoint from our server. Google learns that you signed in to Cutlist. None of your footage, transcripts or clips goes anywhere near it.
Frames and transcript excerpts go to the model provider as the input to a single request, and the provider’s own API terms govern that request at its end. Nothing we send is sent for training, and we grant nobody the right to use it that way.
What we do not do.
- No ad pixels. No tag manager. No third-party analytics, no session recorder, no heatmap.
- No tracking cookies, and therefore no consent banner - there is nothing to consent to.
- Your footage is not training data. We do not train on it and we licence it to nobody who would.
- We do not sell, rent or share your data. Not with brokers, not with ad networks, not with anybody.
- We do not post on your behalf, and we hold no social account credentials.
- We do not read your clips for fun. Access to stored files is for running the service and answering a support request you started.
The first two are checkable rather than promised. This site ships six runtime dependencies - the framework, the renderer, the database client, a schema validator - and not one of them is a tracker. The page you are reading loads no script from any other origin.
Everything herehas an expiry.
Retention is a constant in the code, not a policy someone remembers to apply. A sweep deletes the row, then the files, then hands the bytes back to your allowance.
Clips: 30 days
Working output, not an archive. A sweep deletes the row, then the video, poster and SRT files, then returns the bytes to your allowance. The studio counts each clip down so nothing vanishes unannounced.
Uploads: 2 days
Source files go sooner than the clips cut from them. Once a render is finished there is no reason for us to be holding your original.
Sessions: 30 days
A session expires on its own, and signing out deletes the record server-side rather than asking a cookie to please stop working.
Job and ledger rows: while the account exists
The job record outlives the clip it produced. It is what lets you see what you asked for, what it cost and why, months later. Deleting the account deletes it.
Account: until you end it
There is no dormancy sweep and no quiet expiry of an account you stopped using. If you want it gone, ask, and it goes.
Deletion reaches our copy. It does not reach a copy you have already downloaded, posted, or handed to somebody else.
What is actuallyin the code.
Nothing on this list is aspirational. Each one is a mechanism you could point at in the source.
Passwords
scrypt, per-account salt, constant-time comparison, ten character minimum. Sign-in does the same work whether or not the account exists, so timing cannot be used to enumerate addresses.
Sessions
The cookie is httpOnly and SameSite=Lax, marked Secure in production, and holds a 32-byte random token. We store only its hash, so a copy of the database does not yield a working session.
Signup does not confirm
A signup blocked on an address already in use is told the address cannot be used, never that it is taken. An account list is not something a stranger should be able to assemble from the signup form.
URLs you supply are checked
A source URL that resolves to a private, loopback, link-local or cloud-metadata address is refused, at submit and again on the worker immediately before it connects.
Storage keys cannot escape
Every key is pattern-checked and the resolved path is re-checked against the storage root, so no key can read a file outside it.
Only registered artifacts serve
The file route refuses anything that is not a clip or an upload we have a row for. A stray file in the storage directory can never be read back out.
Two limits worth knowing. A clip URL is a capability: the key is long and random and only ever handed to you, but anyone you send that link to can fetch the file without signing in. And your footage is stored so it can be processed, which means it is not encrypted in a way that would stop us from reading it - anyone claiming otherwise about a tool that watches your video is describing something that cannot work.
There are two.
cutlist_session holds a random token that means nothing without our database, and its only job is to keep you signed in. Neither one is a tracking cookie and neither is shared with anybody.
httpOnly
No script on the page can read it, which is what stops a cross-site script from lifting your session.
SameSite=Lax
It is not sent on a cross-site POST, which is what stops another site acting as you.
Secure
Sent over HTTPS only, in production.
30 days
Then it expires. Signing out revokes it server-side immediately.
The second is cutlist_returning, and it holds the single character 1. It records that an account has been signed in to from this browser, so the studio opens on a sign-in form rather than greeting somebody who already has an account as a stranger. It names no account, carries no identifier, grants no access and is never read by anything but that one decision. Same httpOnly, SameSite=Lax and Secure settings as the session cookie; it lasts a year, and clearing your cookies removes it.
Access, export,deletion.
Most of this is a button rather than a request form, because a right you have to email for is a right with friction on it.
See it
The studio shows every project, job and clip, what the model saw and heard on each one, your storage bar and your credit balance. The ledger behind that balance records every movement with the job that caused it, but it has no screen yet - ask and we send you your rows.
Take it
One zip per job: every clip, its SRT and its post caption as a text file. Or take a single clip or SRT on its own. No watermark on any plan, including the trial.
Correct it
The brand kit is editable in the studio. Your name, email and password are not - changing those means writing to us. That is friction we put there by not building the screen, and we have not built it yet.
End it
Ask and the account goes: the project, every job, every clip, every upload, every session and the ledger, all cascaded and deleted. We do it by hand today, so allow a few working days.
Age, borders,and who to write to.
Age
You must be 18, or the age of majority where you live, to hold an account - the same line the terms draw. We do not knowingly hold an account for a child. If you believe we do, email us and it goes.
Where it happens
The service and the model provider both process data in the United States. Using Cutlist from elsewhere means your footage is processed there.
Changes
This page carries the date it last changed. A change that widens what we collect or where it goes will be announced by email before it takes effect, not backdated into a diff.
Contact
hello@heckraiser.com. Cutlist is a HeckRaiser Productions tool, and HeckRaiser Productions is the party responsible for the data described here.
Read this before you rely on it
This policy was written by the people who built the product, from the code that enforces it. It is accurate about how the service behaves. It has not been reviewed by counsel, it does not use the defined terms a regulator will look for, and it is not legal advice.
We would rather post an honest draft and label it than copy a boilerplate notice from somewhere else and let you assume it was checked. A reviewed version will replace this one, and the last-updated date will change when it does.
Spotted something wrong or something missing: hello@heckraiser.com