What iLoveTimers Stores in Your Browser

This inventory comes from direct localStorage reads and writes in the production application. Version suffixes are part of the keys. A later implementation may migrate a format rather than reading an incompatible older value.

Most React state is in memory unless a route explicitly writes it to storage. The basic countdown's active monotonic target, ordinary stopwatch elapsed time and laps, reaction-test rounds, alarm runtime state, and many form values disappear when the page reloads or closes. Saving a named preset on a supported tool stores only its reusable setup, not its active countdown or current phase.

The speedcubing timer makes the distinction visible: its three settings persist, while solve results and averages remain in page memory and are cleared by refresh or closure. The multiple-timers route saves labels, configured durations, and the last remaining values, but intentionally restores them paused rather than pretending the page kept running.

The Countdown Timer, Pomodoro Timer, HIIT Timer, Time Zone Converter, and Time Zone Meeting Planner can represent selected settings in a versioned URL. That URL is not local storage. Anyone with the link, and services involved in transporting or requesting it, can read its date, duration, timing, work-window, or timezone settings. The links exclude arbitrary labels, notes, history, current phase, running state, remaining time, alarm state, and preset names.

Opening a shared setup leaves the tool stopped or ready and does not create a preset. The Time Zone Converter does not replace its saved preferences just because a setup link was opened. Named presets are explicit localStorage records on the four tools listed in the inventory. They remain local to the browser profile unless the browser itself moves or synchronizes site data.

The browser gives each origin a separate local storage area. Data saved for the HTTPS iLoveTimers origin is available to scripts running on that origin in the same browser profile. Unlike cookies, local-storage values are not automatically attached to every web request. Page code can still read and use them, so notes, labels, rates, and coordinates should be treated as information stored on that browser, not as an encrypted vault.

There is no iLoveTimers account synchronization. Opening the site in a different browser, profile, device, or private window normally starts with separate storage. Clearing browser site data removes saved values and preferences. Browser import, profile sync, enterprise policy, or backup behavior belongs to the browser environment and is not controlled by iLoveTimers.

Storage APIs can throw when persistence is disabled, restricted, or out of quota. The theme, consent, and tool implementations wrap reads and writes in error handling. Missing or invalid theme data defaults to light. Several JSON-backed tools validate a version and expected fields before restoring; malformed data is ignored or replaced with safe defaults. The astronomical clock removes a corrupt preference entry. Named preset stores validate the root version, tool identifier, schema version, name length, timestamps, and route-owned configuration. A bad record is ignored without discarding valid sibling records. Older version-1 preset roots are rewritten in the current shape after the next successful preset change.

Validation is intentionally route-specific because an agenda, a timer list, and a timezone preference have different shapes. A fallback means the tool remains usable. It does not recover the overwritten or cleared value. Export important billable or planning information before clearing site data if you need to retain it elsewhere.

iLoveTimers stores the analytics choice as allowed or declined. When analytics is not configured or consent is not allowed, capture remains stopped. If the user allows configured analytics, the PostHog client is initialized with local-storage persistence, no session recording, no autocapture, masked text and element attributes, no person profile, and a restricted manual-event property list. Declining stops capture and resets analytics state.

The current data-handling statement and controls are on the Privacy Policy and Cookies Policy. The footer's Analytics preferences control lets a user revisit the choice.

• Use a tool's own clear action when it provides one, such as clearing BPM history or using Delete all for that tool's named presets. This is narrower than clearing all site data.
• Use browser site-data controls for ilovetimers.com to remove all local preferences and saved tool state for that origin.
• Expect theme, consent, event, agenda, timer, timezone, and other locally saved choices to return to defaults after a full clear.
• Copy or export information you need before clearing. Local storage is convenient persistence, not a durable backup format.

These external references support the browser and standards behavior described above. iLoveTimers implementation details are identified separately in the guide.

• HTML Standard: Web storage: defines origin-scoped localStorage and sessionStorage, storage failures, and browser controls for deleting stored data
• MDN: Window.localStorage: explains that local storage is origin-specific, can persist across browser sessions, and may be unavailable because of browser policy
• WHATWG Storage Standard: defines origin-based storage keys, quotas, and user-agent storage policy used by web storage
• iLoveTimers Privacy Policy: states the site's current user-facing data and analytics practices