Privacy Policy

Home Theater Builder is a free tool for planning a compatible home theater system. This page explains, plainly, what data the site collects, why, and what you control. You can browse, build, compare and save without an account; an account is optional, and the sections below say exactly what making one adds and how to take it all back or destroy it.

What we collect

Here’s what we collect:

• Cookies: one if you never sign in, three if you do. If you never sign in, there is exactly one. When you save a build we set htb_uid, containing a random, unguessable id — not your name, email, or any identifying information. It has no purpose beyond letting you find and delete your own saved builds later without an account. Signing in adds two more. The first is the session cookie our authentication provider sets: it carries the token that proves this browser is signed in, it is HttpOnly, so no JavaScript — ours or anyone else’s — can read it, and it is only ever sent over HTTPS. The second is htb_sess, whose entire value is the digit 1: no id, no token, no address, no timestamp. It exists so a cached page can tell whether it is worth asking our server who you are, and it is never trusted to answer that question. None of the three is used for advertising, and none is shared with any ad network or tracker.
• Local storage, for your in-progress build. While you are using the builder, your current part selections — and the room size you set in the room plan — are kept in your browser’s local storage so the page survives a refresh. That copy never leaves your device on its own. It leaves when you click Save, which stores it on our server under the cookie id above — or under your account, if you are signed in — or when you use any of the buttons that hand you a link to the build — Share, and Copy as forum text, which writes that same link into the post it builds for you; the next item says exactly what the room part of that link contains.
• Room dimensions, if you use the room plan. The room plan works from three numbers — width, depth and height, in feet, rounded to the nearest half a foot and capped to a small range. They describe how big a room is. They are not a location, not an address, and not anything that identifies a home or the person in it. Two consequences follow, and we would rather state them than let you find them out. First, whenever you hand out a link to a build whose room is not the default 20 × 14 × 8 — the Share button, and equally Copy as forum text, which embeds the same link in the post it writes — the numbers travel in the link itself (…&room=22x16x9), so everyone who receives it gets them, as does any service that fetches the link to build a preview card, and as does anyone reading the forum you paste it into; they also appear in ordinary web-server request logs along the way, the same as the rest of the address. We cannot make a query parameter private, so we are telling you it is there instead. Second, a saved build stores the room alongside the parts, on the same row and under the same owner — the anonymous cookie id if you are signed out, your account if you are signed in — so the caveat under “Saved builds” below reaches the room too: on a build that was never attached to an account, once you clear your cookies we cannot verify that the build is yours, so we cannot delete the room stored on it either. Delete the build first if that matters to you, or sign in, where deleting the build — or the whole account — takes the room with it. We never send a room measurement to analytics: not the numbers, not the floor area, not a size band.
• Your account, if you choose to make one. An account stores your email address, the display name and the handle you pick, your display and publishing preferences, and the builds you save while signed in. Passwords are stored and checked by our authentication provider, hashed, never by us and never in our database. If you sign in with Google instead, we store the link to the profile picture Google hands us; your browser then loads that picture directly from googleusercontent.com on every page you view while signed in, so Google sees that a request happened — we send no referrer, so it does not learn which page you were on, and it never learns anything about a signed-out visit. We never see your Google password. The only email we send you is the one you ask for: address verification, and password reset.
• A profile picture, if you upload one. You can upload your own picture instead of using your initials or your Google photo. We store the file in our own storage at supabase.co, and that is where your browser — and everyone else’s — loads it from. Before we store it we strip the metadata the file carries about itself: the capture location, the camera and phone details, and the timestamp. That removes what the file says; it does not change what the picture shows, and only you can judge that. Treat an uploaded picture as public: it is shown next to any build you publish, so it is visible to anyone who can see that page, and copies may persist in caches for a while after you change it. You can replace it or remove it from Settings at any time, and removing it puts your initials back.
• Builds you saved before you sign in. A build saved without an account belongs to that device’s htb_uid cookie, which is evidence about a browser and not about a person. So when you sign in on a device that has some, we ask — once, plainly, listing them — whether they are yours. We never move them silently. Decline and nothing happens: they stay on the device, still visible, still yours to delete. Accept and they move onto your account, and the confirmation that follows carries an Undo that puts them straight back on this device. That Undo is offered in that moment only — we have no way to reverse a claim afterwards, so if you are not sure, decline. The question exists because of the shared, family and library browser, where the builds already on the device may belong to someone else.
• Anonymous, aggregated usage analytics. We use Vercel Web Analytics, which does not use cookies and does not identify individual visitors. It counts things like which pages and product categories get visited, whether a search returned results (never the words you searched), and which outbound retailer links get clicked, so we know which parts of the site are useful. Vercel discards the underlying visitor signal within 24 hours. We never see your IP address, name, or any personal identifier through this system. Signing in does not change that: the sign-in events we count record only which method was used, never who used it, and no account id, handle or address is ever attached to an analytics event.
• Error monitoring, only when something breaks. We use Sentry to catch and diagnose crashes: when the app errors, Sentry receives the error message, the stack trace, and — only for that one session, never for ordinary browsing — a session replay with all text and input values masked and all images and video blocked, so we can see the layout and interaction sequence that led to the crash without seeing what you typed or looked at. Separately, that same crash also sends a minimal report of our own (page path only, no query string, plus the error message) to our own server so it shows up in our logs. Neither system runs, or collects anything, unless the app actually errors.

Saved builds

A saved build stores the name you gave it, the parts you selected, the room you planned it for, and a price snapshot. Who it belongs to depends on how it was saved. Saved while signed out, it is attached to the random cookie id above and to no real identity, and clearing your cookies makes it unreachable from your side, because nothing ties an anonymous build to you except that cookie. Saved while signed in, it is attached to your account as well, so it follows you to another browser and survives a cookie clear. Either way, you can delete any saved build at any time from the Saved page.

We keep a saved build indefinitely, until you delete it yourself; there is currently no automatic expiration. On an anonymous build — one that was never attached to an account — once the cookie is gone, no other field on a saved build identifies who saved it or ties it back to you, so we cannot verify that an emailed request refers to a build that is really yours, and we cannot locate or delete one specific saved build on request after that point. On a build that is attached to an account there is no such gap, and no email is needed: see “Your account: export and deletion” below.

Your account: export and deletion

Everything an account holds is yours to take and yours to destroy, from Settings, without asking us and without emailing anyone.

• Download my data. Settings hands you a JSON file containing your profile — email address, display name, handle and preferences — and every build on your account, with the parts identified by product id. It is an ordinary download link: nothing runs, and the file goes straight to your machine.
• Delete account. Settings destroys, in one transaction: every build on your account — except one you have published, which is covered in “Builds you publish” below; your profile row, and with it your display name and handle; and your sign-in method, so the email address is free to start a fresh account. There is no undo and no grace period. Builds you claimed from a device go with it. Your handle is then retired rather than recycled for 12 months, so nobody can immediately take the name that was yours.

Deleting an account does not reach a build you saved while signed out and never claimed: that build still belongs to the htb_uid cookie on the device it was saved on, and the “Saved builds” caveat above is the one that applies to it. Delete it from the Saved page before you go if you want it gone too.

Builds you publish

Everything above describes a build you keep to yourself. Publishing a build to Explore is a separate, deliberate act — per build, never automatic, and never a setting that turns future saves public — and it changes what is private about it completely. Publishing requires signing in, because a published page has to stay removable by the person who put it there, and an anonymous cookie cannot survive being cleared.

If you publish a build, six things become public on the open web: the name you gave it, the handle on your account (or the word “Anonymous”, if you choose that for that build), the description you wrote, the parts you picked, the room size if the build has one, and the date you published. Your email address, your display name and the rest of your account are not part of a published build. Anyone can read the page, including search engines and any service that fetches it — a published build is not a link that is merely hard to guess. Edits you make later update the public page, and a person reviews a build before it first appears.

You can unpublish at any time, from the build or from your Saved list, and it comes off the site immediately. What we cannot do is un-publish it from anywhere else: search engines, archives, caches, screenshots and anyone who copied the text keep whatever they already fetched. That is a limit of the web, not a policy choice, and we would rather say it than let you assume otherwise.

Which promise wins. Once a build’s address has been public, we do not let that address break: deleting a published build removes it from Explore and clears what you wrote, but keeps the row and its address so the link sends visitors back to Explore instead of dying. So for a build you published, permanent address beats complete erasure — a page cannot honestly promise both. If you need the record removed rather than unpublished, including the name, email support@hometheaterbuilds.com and say so: that path retires the address outright instead of redirecting it. Because publishing requires an account, we can verify that request — which is exactly what we cannot do for the cookie-scoped saved builds described above.

And that is true when you delete your account, too. Closing an account does not shorten what publishing already made permanent. A build you published keeps its row, its address and the name you gave it, so the link still resolves; if a moderator had ruled on it, that record stays as well, because a take-down its subject can erase by closing their account is not a record. Everything that ties the build to you goes with the account: it leaves Explore, and the link between it and you, the description you wrote and the handle-or-“Anonymous” line are all destroyed. So the deletion above is complete for every build except a published one, and for that one the same trade applies — permanent address, not complete erasure. If you want the name and the address gone as well, the email route in the paragraph above is how, and it works after the account is closed.

Outbound retailer links and affiliate disclosure

Buy links on this site go to retailers’ own websites. Some outbound links may be affiliate links: where an affiliate relationship exists, we may earn a commission if you buy something after clicking through, at no extra cost to you. This never affects which products we show, how we rank them, or what our compatibility checks say, those come from the stored spec data alone. When we click through to a retailer, that retailer’s own site handles the transaction and is governed by their own privacy policy, not ours. If we join an affiliate network in the future, that network may itself process click data for commission tracking; we will update this page to name it if so.

Who processes data on our behalf

The site is hosted on Vercel (hosting, content delivery, and the analytics described above) with its catalog stored on Supabase (a managed Postgres database). Error monitoring and error-triggered session replay, described above, run through Sentry. All three process standard web request data (like IP addresses, as part of ordinary internet routing, abuse prevention, and — for Sentry — crash diagnosis) as our infrastructure providers. None of them uses site data for their own advertising.

Supabase also runs authentication. If you make an account, it holds your email address and either your hashed password or the fact that you sign in with Google. The two emails an account needs — address verification and password reset — are delivered by Resend, our email delivery provider, which processes recipient addresses on our behalf to send them. If you upload a profile picture, Supabase stores that file too, and serves it publicly from supabase.co.

Google is a processor only if you choose Google sign-in. In that case Google learns that you signed in to this site, and returns your email address, your name and a link to your profile picture. Your browser then fetches that picture from googleusercontent.com on each page you view while signed in, which tells Google that a request happened but not which page it was for — we send no referrer. If the picture is ever unreachable, the site draws your initials instead and nothing is fetched. Sign in with an email address and password and Google is not involved at all.

Children’s privacy

This site is not directed at children under 13, and we do not knowingly collect personal information from anyone in that age group.

Your choices

• Clear your cookies or local storage at any time through your browser settings to reset your anonymous id and locally stored build.
• Delete any saved build directly from the Saved page.
• If you have an account, take everything with Download my data in Settings, or end it with Delete account there — both are immediate, neither needs us, and deletion is final. See “Your account: export and deletion” above for exactly what goes.
• Email support@hometheaterbuilds.com with any question about your data. Note that on a build with no account behind it, once your cookies are cleared no field on it identifies you, so we cannot verify or honor a request to delete that one build — see “Saved builds” above.

We do not honor browser “Do Not Track” signals differently from any other visit, since the site collects no cross-site tracking data for DNT to meaningfully change.

Changes to this policy

If what the site collects changes, this page changes with it and the date at the top updates. Accounts are the most recent such change, and they are described above in full. We do not add advertising trackers, sell or rent what we hold, or start collecting a new kind of data without saying so here first.

Contact

Questions about this policy or your data: support@hometheaterbuilds.com.