Legal

Privacy Policy

There are no accounts here, so there is no profile of you to keep. What the server actually holds is a link while it is being processed, the audio it produced while that stays cached, a request log, and one number counted against your IP address for the length of a day. This page says what each of those is, how long it lasts, and who else your request touches on the way. Supporter payment and gift key records are described separately below.

Last updated 2026-10-24

What this site never collects

• No account. There is no sign-up form, no login, no password and no email address needed to use the free downloader. Supporting us on Ko-fi requires an email for gift key delivery.
• No connection to your Apple Music account. You are never asked to authorise one, and the service cannot see your library, your private playlists or your listening history — only what is publicly visible behind the link you paste.
• No download history attached to a person. Nothing stored ties a link to a name, an email or a supporter order. The request log is the one place an address and a path sit on the same line, and how long that lasts is stated below.
• No advertising identifiers, no fingerprinting script, and nothing sold, rented or handed to a data broker.
• No card numbers or payment credentials. Ko-fi and its connected payment provider process supporter payments.

Supporter payments and gift key emails

When you support us on Ko-fi, we receive your checkout email, transaction and notification IDs, amount, currency and payment time. We retain those order details, the gift key hash and status, and email delivery records to issue your key, support resends and handle refunds. These records are kept indefinitely, including for lifetime gift keys, and are not linked to your download history. The gift key is derived from the order; the key records store its hash. Resend receives your email and the gift key email content to deliver it. Ko-fi, PayPal or Stripe process the payment under their own privacy policies. Existing Gumroad keys are checked with Gumroad when redeemed. Support may also grant a key to your email or link an existing verified Gumroad key for recovery. Imported Gumroad keys are stored encrypted; generated keys are derived from their record and stored as hashes. We retain administrator action records to manage these keys.

If you request keys by email, we use that address to locate all saved, active gift keys and send them together in one email to the original recipient. The webpage never displays a key or confirms whether an address has purchased. To prevent repeated emails, we keep a hash of the requested address and request times for about two days, with regular cleanup. Queued recovery messages are encrypted for delivery retries; completed or canceled recovery records are removed after about two days. We also apply a short-lived per-IP request limit.

What the server does hold, and why

• The link or search text you submit. It goes to the server, which reads the public metadata behind it — track titles, artists, durations, artwork addresses — and sends that list back to your browser. The result is cached for about ten minutes so a reload or a second paste of the same link does not repeat the lookup, and the expired copy is held about a day longer as an outage fallback — when Apple Music stops answering, a day-old track list beats an error page. That cache is keyed by the link, never by whoever pasted it, and nothing beside it records who pasted it.
• Your IP address. Two uses, both defensive: rate limits, which stop one visitor saturating the download workers, and the daily track quota described in the next section. It is not used to build a profile, and the quota counter itself holds no list of what you downloaded.
• Request logs. Each request writes a line carrying its IP address, path, response status, user agent and timing. A download job writes more than that, and it is worth naming rather than hiding behind “internal ids”: the link you pasted, and for each track its title, its artist and its Apple Music URL, alongside the job and track ids. That is what makes a failed download diagnosable, and it does mean a line describing what you downloaded sits beside your address for as long as the window below allows. Those lines are how a failed download gets diagnosed and how abuse gets found. They go to two places: a size-capped file on the host, which rotates — when it fills a new one starts and the oldest is deleted — and a search index on the same machine, which is what actually gets queried when something breaks. That index keeps 90 days, or five gigabytes of lines, whichever runs out first. So 90 days is the outside limit for a log line about your request, and a busy month reaches it sooner.
• The audio files. A job writes into its own folder, and a janitor pass deletes finished jobs and their folders twenty-four hours after they end. Separately, a finished track is kept in a shared cache keyed by a hash of the track, the format and the bitrate — never by who asked for it — so a popular song is fetched from its source once rather than a thousand times. That cache has two tiers and they expire differently: the copy on our own disk lasts seven days, or less when the size cap evicts it, while the copy in object storage behind it is kept indefinitely, because re-fetching a track nobody has asked for in a year still costs a download. Neither tier holds a visitor id — the key is the hash, so what is kept is audio, not people.
• Usage analytics. Page views, referrer, country, browser and screen size, plus a few product events — a link was resolved and how many tracks it held, a search happened, a track was saved, an interaction-latency measurement. Deliberately not in any of them: the link you pasted, the words you searched for, or the title of anything you played or saved. Analytics rows are kept for more than a year and are grouped into a visit, so a URL or a song title in one would be exactly the durable record of your listening that this page says does not exist. Each event is a row rather than a running total, and the rows are grouped by an id the tracker derives from your address and your browser instead of storing the address itself. Those product events run on our own infrastructure and their retention is in the table below. We use self-hosted OpenPanel for page views and product events. Page addresses include only the path and campaign tags. Do Not Track and Global Privacy Control disable this tracker. A random ID held only in page memory connects these actions to request timings and job outcomes. It disappears on reload. Separately, our operational ledger records anonymous job outcomes, HTTP delivery status and authenticated payment totals for up to 13 months, without pasted links, search text, song metadata, gift keys or email addresses.
• Session replays. Under the same switches as the analytics above, we record a masked replay of how a visit used the page: its layout, pointer movement, clicks, scrolling and window size, so we can see where the tool confuses people or breaks. It is masked before it leaves your browser. Our own interface text stays readable; everything else — the title and track list of whatever you opened, search results, the player, your download history — is recorded as asterisks, every value you type (a link, a search, a gift key, an email) is recorded as asterisks, and covers and other images become empty boxes. Our analytics server then rebuilds each recording from a whitelist and masks anything that still looks like a link, an email or a key. Replays are kept for 30 days. If only some visits are recorded, a one-character flag in this tab’s sessionStorage remembers whether yours is one of them; it is gone when the tab closes.

The one counter tied to your IP address

The counter is a single integer per address per day. It records how many tracks were accepted, not which ones — there is no list of songs beside it, and no way to reconstruct one from it. It is mirrored to a file on disk because the service restarts often, and a memory-only counter would hand out a fresh budget on every deploy. At 00:00 UTC the day rolls over and the previous day’s counts are dropped. If you share an address with other people — an office, a campus, a mobile carrier’s NAT — you share the budget with them too. That is the honest cost of running a quota without accounts, and the alternative would be asking you to create one.

Cookies, and the one thing kept in your browser

Our OpenPanel usage analytics sets no cookies and does not store a persistent analytics identifier in your browser. The site does not load Google Analytics.

You can disable usage analytics with your browser’s Do Not Track or Global Privacy Control setting. Downloading works without analytics.

One value is written to your browser’s own localStorage: your theme choice, stored under site-theme as system, light or dark. It stays on your device, is never sent anywhere, and the server has no idea what it says. Clearing site data removes it and the page goes back to dark.

The CDN in front of this site may set a security cookie of its own for bot mitigation. It belongs to that network rather than to us, carries no profile of you, and is not read by anything on this site.

How long each thing lasts

Who else your request reaches

• The CDN in front of this site. Every request passes through Cloudflare before it reaches the server, so that network terminates TLS and sees your address and the URL you asked for, and applies its own bot mitigation. It handles that as our infrastructure provider, under its own terms.
• Object storage for the shared track cache. It holds audio objects named by hash. No visitor identifier appears in a key or in an object.
• The audio sources. When a track has to be fetched, our server fetches it over its own outbound connection — not yours. The source sees a request from us and never learns your address. For the downloader, your browser only ever talks to this domain.
• Apple Music. The same: the public metadata behind your link is read server-side. Pasting a link here tells Apple Music nothing about you and does not touch your account.
• No ad network, data broker or mailing list. Usage analytics runs on infrastructure we operate.

Your rights

Depending on where you live you may have the right to access, correct, erase, port or object to the processing of your personal data, and to complain to your local supervisory authority. Californian readers also have the right to know what is collected and to have it deleted, and to opt out of its sale — nothing here is sold, so that last one has nothing to act on.

The practical answer is that almost nothing held here is personal data in a shape we could look you up by. Supporter orders are an exception: we can locate them using the payment email or transaction ID. What can genuinely be acted on differs by item, so here it is plainly. The daily quota count for an address can be reset on request. Log lines cannot: the store ages entries out on the 90-day and size-cap windows described above and has no selective delete, so an erasure request for them is answered with that fact and the date they expire, rather than with a deletion that did not happen.

How to ask

Email support@amtomp3.com with what you want done and enough detail to find it. Replies go out within 30 days and usually much sooner. Copyright complaints are not privacy requests and are handled separately — the copyright policy lists the address and the elements a notice should contain. What the service is, and what it may be used for, is set out in the terms of service.

Changes to this policy

The date under the heading moves whenever this text does, and because there is no account and no mailing list, that date is the only signal — check it if the wording matters to you. This policy covers amtomp3 and nothing else; a site you reach from a link here has its own.