5 Minute Timer, 10 Minute Timer, 25 Minute Timer — One URL for All

You need a 5 minute timer. You search for one, land on a page covered in ads, click through a cookie banner, click the "5" preset, and start. Tomorrow you need ten minutes and repeat the whole ritual. There's a better shape for this: put the duration in the URL. One page, infinite presets, all of them bookmarkable.

#TL;DR

• ?t=5m on iKit's timer opens countdown mode with five minutes loaded.
• The parser takes 5m, 90s, 1h+30m, 25:00, or a bare 10.
• Any preset URL is bookmarkable, pinnable, and shareable in chat.
• Chrome site search and Firefox keywords turn presets into two keystrokes.
• The URL presets the duration; you still press Start, by design.

#How to set a 5 minute timer in your browser

The fastest path to a five-minute countdown is not clicking a button — it's loading a URL that already knows the answer.

#The one-parameter version

iKit's Stopwatch & Timer reads a t query parameter on load:

https://timer.ikit.app/?t=5m

That switches the page into countdown mode and loads 300,000 ms into the display. No account, no server round-trip — the string is parsed by JavaScript in your tab, and the duration never leaves the machine.

Two sibling parameters cover the other modes:

https://timer.ikit.app/?stopwatch
https://timer.ikit.app/?pomodoro

These are presence-only flags — no value needed. ?stopwatch opens the count-up view with lap splits; ?pomodoro opens the focus/break cycler.

#Which duration formats the parser accepts

The parser is deliberately forgiving, because people type durations in wildly different ways.

Two rules are worth internalising. First, a bare number means minutes — ?t=10 is ten minutes, not ten seconds, matching what every kitchen timer does. Second, colon form is read right-to-left: two segments are MM:SS, three are HH:MM:SS.

#Why the timer does not start automatically from the URL

This trips people up, so it's worth being explicit: ?t=5m loads the duration but does not press Start for you.

That's not laziness. Browsers require a user gesture before a page may play audio, and a timer whose alarm is silently blocked is worse than no timer at all. Loading a link is not a gesture. By making you press Start (or tap the space bar), the page earns the right to make noise five minutes later. The same gesture is what lets it ask for notification permission.

#10 minute timer, 25 minute timer, and everything in between

Once you understand the shape, you stop thinking in presets and start thinking in links.

#A copy-paste table of the common ones

These are the durations people actually search for, in URL form:

Bookmark the two or three you use weekly and you never open a timer's UI again — you open the timer you wanted.

#How to generate preset links in JavaScript

If you're building a dashboard, a Notion page of team links, or a CLI that opens the right timer, generate the URLs rather than typing them:

const timerUrl = (duration) => {
  const u = new URL("https://timer.ikit.app/");
  u.searchParams.set("t", duration);
  return u.href;
};

timerUrl("5m");     // ...?t=5m
timerUrl("1h 30m"); // ...?t=1h+30m

Note the second result. URLSearchParams serialises using the application/x-www-form-urlencoded rules from the WHATWG URL Standard, which encode a space as + rather than %20. Both survive the round trip here, because the same API decodes + back to a space on the way in. If you hand-build the string instead, %20 works equally well — but a raw space does not.

This is the one place these links bite people. Form encoding turns a space into +, generic percent-encoding turns it into %20, and mixing the two is how you end up with a literal plus sign inside your duration string. The URL encoder is a quick way to see what a given value actually becomes before you ship the link.

#What happens if the duration is nonsense

Garbage in the parameter is ignored rather than fatal. ?t=banana parses to zero, the guard rejects it, and the page falls back to whatever duration you last used — which it restored from localStorage a moment earlier. The URL wins when it's valid; your last session wins when it isn't. That ordering means a broken link never leaves you staring at 00:00.

#How to bookmark a timer preset in Chrome, Firefox, and Safari

A bookmarkable URL is only half the win. The other half is not needing the bookmarks bar at all.

#Chrome and Edge: site search shortcuts

Chromium browsers let you register a URL pattern with a keyword under Settings → Search engines → Site search. Add:

Name:    Timer
Shortcut: tm
URL:     https://timer.ikit.app/?t=%s

Now typing tm, Tab, 25m in the address bar opens a 25-minute countdown. The %s is replaced with whatever you type after the keyword. Because the duration parser accepts bare numbers, tm Tab 10 works too.

#Firefox and Safari

Firefox has the same feature under a different name: right-click a bookmark, choose Edit Bookmark, and give it a keyword. Point the bookmark at https://timer.ikit.app/?t=%s and the keyword behaves exactly like Chrome's shortcut.

Safari has no keyword system. The pragmatic substitute is three pinned tabs — 5m, 25m, 1h — or a Shortcuts.app action that opens a fixed URL, which also gets you a Siri phrase and a Home Screen icon on iOS.

#Installing presets as app shortcuts

If you install the timer as a PWA, the shortcuts member of the web app manifest turns presets into a right-click menu on the app icon. Per the MDN web app manifest reference, each entry is just a name and an in-scope URL:

{
  "shortcuts": [
    { "name": "5 minute timer",
      "url": "/?t=5m" },
    { "name": "25 minute focus",
      "url": "/?t=25m" }
  ]
}

Long-press the icon on Android, right-click it on Windows or ChromeOS, and the presets are one click deep from the taskbar.

#Why use a URL parameter instead of a separate page for each timer

Plenty of timer sites ship /5-minute-timer, /6-minute-timer, /7-minute-timer as literal pages. It's an SEO tactic, and it has real costs.

#One code path, no combinatorial explosion

A parameter handles every duration a human might want with a single template and a single parser. Static pages handle only the ones someone remembered to generate — which is why those sites have a 12-minute timer but not a 12-minute-30-second one. Every new page is another thing to keep in the sitemap, another thing to translate, another thing that can drift out of sync when the timer logic changes.

#Query string versus hash fragment

Both ?t=5m and #t=5m survive a bookmark, so why the query string? Because the query string is part of what a link preview, a chat unfurler, and an analytics tool can see and normalise, while the fragment is client-only. The query string is also what browser keyword shortcuts substitute into. The fragment's one advantage — never hitting the network on change — doesn't matter for a page that's already loaded.

#Keeping the URL honest with replaceState

If the page lets you edit the duration after load, the URL should follow. Use history.replaceState(), not pushState():

function syncUrl(duration) {
  const u = new URL(location.href);
  u.searchParams.set("t", duration);
  history.replaceState(null, "", u);
}

pushState would stack a history entry for every keystroke, so Back would walk you through 5m, 5m3, 5m30 instead of returning to the previous site. replaceState rewrites the current entry in place. One caveat from the spec: it throws a SecurityError if you call it too frequently, so debounce it behind the input rather than firing on every keyup.

#Where URL presets stop helping

Honest limits, because a timer you trust incorrectly is worse than one you don't trust at all.

#The tab has to stay open

A browser timer lives in the page. Close the tab and it's gone — a link cannot resurrect a countdown that's already running. Minimising the window or switching tabs is fine; the countdown holds an end timestamp and redraws when you return. For anything with real consequences, keep a phone alarm as the backstop.

#Background tabs repaint late

Browsers throttle JavaScript timers in hidden tabs to save battery, so the display can lag by up to a second while you're away. The underlying arithmetic is unaffected — the page compares against a monotonic clock, not a tick counter — so the number snaps to the correct value the moment the tab becomes visible again. This is a rendering artefact, not drift.

#The URL is not a scheduler

?t=5m says "five minutes from when you press Start", not "at 3 p.m.". If you want a fixed calendar moment — a launch, an exam, a deadline — that's a different tool: a countdown timer anchors to a date instead of a duration. And if you're converting between a wall-clock time and an epoch value while wiring that up, the Unix timestamp converter is the faster path than doing the arithmetic yourself.

#References

• URLSearchParams — Web APIs | MDN — parsing and serialisation behaviour, including the +-as-space rule used in the link-builder examples.
• URL Standard — the application/x-www-form-urlencoded percent-encode set that decides how a query value is written.
• History: replaceState() method — Web APIs | MDN — same-origin requirement and the SecurityError thrown on over-frequent calls.
• shortcuts — Web app manifest | MDN — manifest fields used for the PWA app-shortcut example.

#Related on iKit

• How to run an accurate countdown in the browser — the drift and throttling mechanics behind the "background tabs repaint late" section above.
• Online stopwatch with lap times, explained — what ?stopwatch opens, and when counting up beats counting down.
• Why the Pomodoro 25/5 split still works — the reasoning behind the ?t=25m preset and the ?pomodoro mode.