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-08-12· draft, not lawyer-reviewed
Twelve 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. It is stored under a random key and removed 14 days later. Nothing you do with it moves that date: the expiry is stamped when the file lands, and a render neither shortens it nor extends it.
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 250 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.
Your network address
Held as the key of a counter when you sign up, ask for a link, or start an upload, so one machine cannot bury an inbox in mail or fill the disk. It is a counter and not a log: it records how many times, never what you did, it is not attached to your account, and the row is swept a day after its window opened.
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.
That is the content that leaves for a model to read. Separately, the providers that host the service itself - the app host, the database and the object store - hold your account and your footage at rest. They are named one by one, with what each receives and why, on the subprocessors page.
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 seven runtime dependencies - the framework, the renderer, the database client, a schema validator, a mail client - 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: 14 days
Source files go sooner than the clips cut from them, and the count starts at the upload rather than at a render.
Partner API uploads: 30 days
Uploads made through the partner API are removed 30 days after upload. It is a longer window than the studio's, because an integration re-cuts the same source for weeks. Same sweep, same clock.
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.
Rate-limit counters: 24 hours
The counter keyed on a network address, swept a day after its window opened by the same hourly job that clears expired clips. Nothing about it is kept once it is gone.
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 Three.
cutlist_session holds a random token that means nothing without our database, and its only job is to keep you signed in. None of them is a tracking cookie, and none 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.
The third is cutlist_google_flow, and it exists only because this deployment offers “Continue with Google”. It is set the moment you start a Google sign-in and deleted the moment it finishes, lives at most ten minutes, and is path-scoped to /api/auth/google so it is not attached to any other request. It carries the anti-forgery state, the nonce and the PKCE verifier that stop a sign-in being hijacked - a strictly necessary security cookie for the sign-in it protects, and nothing else.
One more thing, in the interest of counting everything. Inside the studio, two functional values are kept in your browser’s localStorage - a remembered editor mode (cutlist:editor-mode) and whether the sidebar is collapsed (cutlist:sidebar-collapsed). They are not cookies, they never leave your browser, and they hold a preference, not an identity.
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.
The same facts,in the defined terms.
Everything above is written to be read. This section says the same things in the vocabulary GDPR and the CCPA use, so someone scanning for a lawful basis or a no-sale statement finds one.
Running your jobs, and storing what comes out
Performance of the contract you enter by making an account (Art.6(1)(b)). Uploading footage and getting clips back is the service itself; it cannot be provided without processing the footage.
Billing and the credit ledger
Performance of the contract, plus our legitimate interest in keeping an accurate, non-editable record of what was charged and why (Art.6(1)(f)).
Security, abuse prevention, the URL checks
Our legitimate interest in keeping the service and the people on it safe (Art.6(1)(f)) - the SSRF guard, the session hashing, the tenant isolation.
Account and service email
Performance of the contract for a sign-in or a receipt, and compliance with a legal obligation (Art.6(1)(c)) for a notice we are required to send, such as a material change to these terms.
Marketing or tracking
No basis, because there is no such processing. We set no tracking cookies and run no analytics, so there is no consent to ask for and no legitimate-interest balancing to run.
California (CCPA/CPRA)
We do not “sell” or “share” your personal information as the CCPA defines those terms, we have not in the preceding twelve months, and we do not process it for cross-context behavioural advertising. Your rights to know, delete and correct are the access, export and deletion paths above, and we do not discriminate against anyone for using them.
International transfers
Processing happens in the United States. If you are in the EEA, the UK or Switzerland, using Cutlist transfers your footage to the US. We have not put a specific transfer instrument - Standard Contractual Clauses, or the EU–US Data Privacy Framework - in place yet, and we will not pretend we have. If your organisation needs one before it can upload, email us first.
The right to complain
If you are in the EEA or the UK, you may lodge a complaint with your local data protection authority. We would rather you told us first, at hello@heckraiser.com, so we can fix it - but the right is yours either way.
Who the controller is
HeckRaiser Productions is the data controller and the party responsible for everything on this page. It is reached at hello@heckraiser.com, the same address as everything else here.
Adding the regulator vocabulary does not change what this page is: a draft written from the code, not reviewed by counsel. It states a lawful basis honestly; it does not claim a lawyer confirmed it.
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, and it states a lawful basis and the regulator terms honestly - but it has not been reviewed by counsel, 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