Privacy

Your video never leaves your computer.

When you drop a video into encodevideos.com, the encoding happens in your browser using your computer’s CPU. Nothing is uploaded to our servers. We have no copy of your file, no temporary cache, no preview thumbnail, no debug log of what you encoded. We can’t see your video because it never travels to us.

That’s true for every encode, every preset, every audio extraction. If you want to verify it yourself, open your browser’s DevTools, switch to the Network tab, drop a video in, and watch — you won’t see a single upload request.

What never leaves your browser

• Your video file
• Its filename
• Its duration, resolution, codec, or any other metadata
• Any trim, rotation, or crop you apply
• The encoded output — it’s a download to your computer, not a round-trip through us

What we don’t collect — ever

• File contents
• Filenames
• Exact file sizes, exact durations, or exact pixel dimensions (we use coarse buckets and short-edge tiers when we count these — see below)
• IP addresses, outside a brief rate-limit window described below
• Anything that fingerprints a session or a person
• Anything sent to a third party — no Google Analytics, no Mixpanel, no Sentry, no ad networks, no embedded pixels

What we do collect (and what’s collected today)

We’re building a tool people use, and to keep it working well we want to know things like “how many encodes happened this week,” “are most encodes succeeding,” and “what kinds of inputs do people throw at it.” We collect those counts on our own server, with no third-party trackers in the loop.

The events we record are limited to:

• page_view — you opened a page on the site (the path only)
• file_loaded — a video was opened in the encoder, with these coarse details (and nothing else):
  • a size bucket (under 50 MB / 50–500 MB / 500 MB–2 GB / over 2 GB)
  • the file’s container format (MP4 / MOV / MKV / WebM / AVI / WMV / FLV / M4V / 3GP / MPEG / other) — detected from the file’s magic bytes, never from the filename
  • a duration bucket (under 30 s / 30 s–2 min / 2–10 min / 10 min–1 hr / over 1 hr)
  • a resolution tier based on the shorter edge (under 480 / 480p / 720p / 1080p / 1440p / 4K+) and an orientation flag (horizontal / vertical / square)
  These help us troubleshoot — for example, if MOV files start failing more often than MP4, or if 4K sources are hitting out-of-memory more often, the aggregate counts let us notice and fix it. None of these fields identifies you or your file individually; they’re categorical bins, not exact values.
• encode_started — an encode began, with the chosen mode (compress or extract) + target (size, preset name, or audio format) + which edit-mode tools were on (trim / rotate / crop, each yes or no)
• encode_completed — an encode succeeded, with a coarse wall-clock bucket (how long the encode itself took, not the source video’s length: under 30 s / 30 s–2 min / 2–10 min / over 10 min)
• encode_failed — an encode failed, with the type (out of memory / corrupt input / unsupported format / generic)
• browser_tier — whether your browser is running our multithreaded or single-threaded encoder (so we know which path users are on)

Those events do not carry your filename, your exact file size, your exact duration, your IP address, a session ID, or anything else. There are no cookies set for analytics. Browsers that send a Do-Not-Track header are excluded entirely — no script runs, no event fires.

This list is the contract. It’s not “the kinds of things we might collect” — it’s all of it. If we ever want to add an event, this page gets updated first.

Support file uploads (only when you choose to send one)

This is the one case where a filename ever leaves your computer, and it only happens after a deliberate, multi-step opt-in by you.

The flow:

1. You email support saying something like “encoding fails on my video.”
2. Support emails back a one-time link.
3. You click the link, see a page explaining what’s about to happen, and choose to drop your file in.
4. Your browser uploads the file directly to a private storage bucket we control. Our server never sees the file content.

What we store, only when you go through this flow:

• The file itself
• The filename you chose — this is the only place it’s ever recorded; it helps support tell uploads apart
• The ticket id from the support reply

Retention is 30 days, enforced by an automatic delete rule on the storage bucket. After that the file is gone — nothing for support to recover, nothing for us to keep. Access is limited to support staff; the bucket is not publicly readable.

The link is signed with a per-environment server-side key; expired or tampered links don’t work. There’s no public way to upload to this bucket without a one-time link issued by support.

If you don’t want to use this path, just don’t click the link — the encoder works the same either way.

Rate-limiting and IPs

We rate-limit at the edge to keep the site responsive for everyone. When you visit a page, your IP is read at the moment of the request, used to count how many requests have come from your address recently, and then discarded. The IP is never written to durable logs and never associated with any other data we hold.

The current limits: 60 page loads per minute per IP, and 1000 requests per IP per day across the whole site (the health-check endpoint at /healthz is exempt so monitoring tools don’t consume the budget). If you trip the limit you’ll see a brief “slow down” page; wait a minute and try again.

localStorage

We may use your browser’s localStorage to remember small UI preferences (like which size button you used last). We never store file contents, filenames, or any video metadata in localStorage.

Questions

Email hello [at] encodevideos.com.