Classroom Timer Hacks: Fullscreen Countdowns That Run the Room

A classroom timer has one job: end an activity without you saying "two more minutes" four times. The browser tab already open on the teaching machine can do it — fullscreen, readable from the back row, with a sound that carries. What follows is the setup, the three browser APIs that make or break it, and the preset links worth bookmarking before Monday.

#TL;DR

• Put the duration in the URL, then go fullscreen: one click per activity.
• Fullscreen exits on tab switch, app switch, Esc and F11.
• Screen Wake Lock stops the projector sleeping; it releases on tab change.
• Browsers block alarm sound until someone clicks — press Start deliberately.
• A timer that never calls a server collects nothing about your students.

#How to put a countdown timer on the classroom projector

The slow version is: search, load an ad-heavy page, dismiss a cookie banner, click a keypad, click Start. Repeated six times a day, that ritual is the reason most teachers give up and use a phone. The fast version is a bookmark.

#One URL per activity

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

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

That opens countdown mode with ten minutes already loaded. The parser takes unit strings (90s, 5m, 1h), combinations (1h+30m), and colon form (7:30). A bare number means minutes, so ?t=15 is a fifteen-minute countdown.

Two sibling flags cover the other modes, and neither takes a value:

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

Because the state lives in the URL rather than in page memory, every preset is a normal link. Put them in a bookmarks folder, in the lesson plan, in the shared drive document the cover teacher will open, or on the class page. A duration stored only in localStorage can be none of those things.

#How do I make a timer full screen?

Every browser exposes the Fullscreen API, which lets a page ask for the whole display and drops the tab strip, address bar and bookmarks bar. The call is one line, and it must happen inside a user gesture:

document
  .getElementById("clock")
  .requestFullscreen();

Two things worth knowing before you rely on it in front of thirty people. MDN notes that users can leave fullscreen at any time with Esc or F11 — so can a stray keyboard press from the front row. And navigating away, switching tabs, or using the application switcher will also exit fullscreen. If you plan to alt-tab to your slides, the timer will not still be filling the screen when you come back.

F11 on the browser window itself is the low-tech alternative. It is less precise — you keep the page's own header — but it survives things the API version does not, and no teacher has ever forgotten where F11 is.

#Why the back row decides your font size

Projected digits are smaller than they look on the teaching machine. A rough working rule from presentation practice: legible text needs roughly one inch of character height for every ten feet of viewing distance. A room whose back row sits thirty feet from the screen wants three-inch digits, which on a typical projected image means the clock should occupy something like a quarter of the screen height. Fullscreen is what makes that possible without zooming the whole page and breaking the layout.

Contrast matters as much as size in a room with the lights on. Dark digits on a light field survive ambient light better than a thin light-on-dark display, which is the opposite of what looks good on a laptop at night.

#Eight classroom routines mapped to timer presets

Most of a teaching week is the same six or seven durations. Here they are as links you can paste straight into a plan.

#Starters, transitions and the first five minutes

The two-minute pack-away timer is the one that changes a room. It converts "start tidying up" — a request a class can negotiate with — into a visible fact that nobody argues with.

#Group work, stations and assessment

For station rotations, the preset link matters more than the timer. Six rotations means six identical restarts, and a bookmark keyed to ?t=8m gets you back to a fresh eight minutes in one keystroke rather than five.

A few routines are better served by other tools:

• Days until an exam or a deadline belongs in a countdown timer pinned to a date, not in a session countdown that resets each lesson.
• Timed writing with a word target pairs well with the word and character counter on the student device while the room timer runs at the front.
• Getting the timer onto thirty devices is a job for a QR code: encode the preset URL, project the code for ten seconds, and every student's phone or Chromebook opens the same countdown.

#Building your own preset row

If you want a row of buttons on a class page, the URLs are ordinary strings:

const mins = [2, 3, 5, 8, 12, 20];
const links = mins.map((m) => ({
  label: `${m} min`,
  href: `https://timer.ikit.app/?t=${m}m`,
}));

Drop those into anchors and you have a personal control panel that works on any device you sign into, because it is just HTML.

#How do I keep the screen from turning off during a timer?

Twenty-five minutes of silent reading is longer than the sleep timeout on most managed devices. The screen dims, the room notices, someone shouts.

#Screen Wake Lock in one call

The Screen Wake Lock API asks the platform to keep the display on while the page is visible. Per MDN it reached Baseline in March 2025 and requires a secure context, so it works on any HTTPS page in a current browser:

let lock = null;

try {
  lock = await navigator.wakeLock.request("screen");
} catch (err) {
  // Refused: low battery, power saving,
  // or the document is not visible.
}

The request returns a WakeLockSentinel. Keep the reference — it is the only way to release the lock deliberately when the activity ends, and releasing it is the polite thing to do on a battery-powered classroom device.

#What releases the lock mid-lesson

The lock is not permanent, and the failure mode is quiet. It goes away when:

• the tab stops being visible (you switched to the slides);
• the operating system enters power-saving or the battery gets low;
• your code calls release(), after which that sentinel is dead for good.

Because a released sentinel cannot be reused, the correct pattern is to request a fresh one when the page becomes visible again:

document.addEventListener(
  "visibilitychange",
  async () => {
    if (lock && document.visibilityState === "visible") {
      lock = await navigator.wakeLock.request("screen");
    }
  },
);

Teacher-facing version: if you leave the timer and come back, glance at it. A tool that re-acquires the lock will be fine. One that does not will let the projector sleep four minutes later.

#Why won't my classroom timer make a sound?

Because browsers stopped trusting pages to make noise unprompted. Chrome's autoplay policy has covered the Web Audio API since Chrome 71, and an AudioContext created before any user gesture starts in the suspended state — it needs a resume() call after a click before it will produce anything.

The practical consequence for a classroom is worth stating plainly: a timer that was set up entirely by URL and never clicked may finish silently. Press Start with an actual click or key press rather than relying on a link that auto-runs, and test the sound once at the start of the day at the volume the room needs. A countdown nobody can hear from the back of a busy room is a countdown you will end up narrating yourself.

#Why does my timer freeze when I switch to my slides?

It probably did not freeze. It got throttled, and a badly built timer never caught up.

#Deadline math beats counting ticks

Browsers slow down timer callbacks in background tabs to save battery. A timer implemented as "subtract one second every setInterval tick" loses real time whenever those ticks are delayed, and the error accumulates across a twenty-five-minute reading period.

The fix is to stop counting and start subtracting. Store the end time once, then derive the display from the clock:

const end = performance.now() + 25 * 60 * 1000;

function frame() {
  const left = Math.max(0, end - performance.now());
  render(left);
  if (left > 0) requestAnimationFrame(frame);
}

Throttling can still make the display update less often while hidden, but the number it shows on return is correct, because it was computed from the clock rather than from how many callbacks happened to fire.

#Running the timer where you can also present

If your teaching machine has a second output, the durable arrangement is: slides on the projector, timer on the laptop screen, or the reverse. Fullscreen applies to one browser window, so two windows on two displays is the only way to have both persistently visible.

The one-device workaround is a spare tablet or an old phone on the desk, opened to the same preset URL. That is the moment the URL-as-state design pays for itself — the "transfer" is just the link.

#Do visible countdowns actually help a class?

Sometimes, and it is worth being honest about when they do not.

#When a countdown helps and when it pressures

A visible timer is good at making a boundary external. "Five minutes left" from the front of the room is an instruction; a clock on the wall is just a fact, and classes argue with facts far less. For transitions, tidying, station rotations and drafting sprints, that is exactly what you want.

It is a poorer fit for genuinely open-ended thinking, and for any student who finds a running clock stressful — a real and common response, not a character flaw. Two mitigations cost nothing: run the countdown without an audible tick, and for assessment tasks, consider a timer visible only to you, with verbal checkpoints, rather than a projected clock that some pupils will watch instead of working.

#Flashing endings and photosensitivity

If a timer signals the end by flashing the whole screen, keep the rate low. WCAG 2.2 success criterion 2.3.1 sets the line at three flashes in any one-second period, and the W3C explicitly notes that content should be assessed at the largest size a user might view it — which, for a projector, is the entire front wall of the room. A slow pulse or a colour change is safe; a rapid strobe on a two-metre image is not something to introduce into a room of thirty children.

#Why a classroom tool shouldn't need a login

Anything that asks pupils to create an account starts collecting personal information from children, which pulls a school into consent and record-keeping obligations — the FTC's children's privacy guidance covers what that means for operators of services directed at under-13s.

A timer sidesteps the whole question by not participating. There is no account, no class roster and no server call: the duration string is parsed in the tab, the countdown runs on the local clock, and closing the page ends it. It is the rare category of ed-tech where "collects nothing" is not a marketing claim but a description of the architecture.

#References

• Fullscreen API - Web APIs | MDN — requestFullscreen() usage, and the note that Esc, F11, tab switching and app switching all exit fullscreen.
• Screen Wake Lock API - Web APIs | MDN — Baseline status, secure-context requirement, sentinel lifecycle and the visibilitychange re-acquire pattern.
• Autoplay policy in Chrome | Chrome for Developers — Web Audio coverage since Chrome 71 and the suspended AudioContext behaviour behind silent alarms.
• Understanding Success Criterion 2.3.1: Three Flashes or Below Threshold | W3C — the three-flashes rule and the instruction to assess content at its largest displayed size.
• Children's Privacy | Federal Trade Commission — COPPA obligations for services collecting personal information from children under 13.

#Related on iKit

• Five-minute timer presets you can put in a URL — the ?t= parameter in full, including browser keywords that turn a preset into two keystrokes.
• Kitchen timer online: twelve recipe presets in one URL — the same preset-and-bookmark pattern applied to running several countdowns side by side.
• Online timer: how to run an accurate countdown — what "accurate" means for a browser countdown, and where the error creeps in.
• Why setInterval drifts and how to build a timer that doesn't — first-principles version of the deadline-math snippet above.
• Why background tabs pause your JavaScript timer — exactly what the browser does to your callbacks when you switch to the slides.
• Building a browser alarm sound with the Web Audio API — how the end-of-activity beep is synthesised, and why autoplay policy silences it.
• Reminders that survive a tab switch, using the Notification API — getting an alert through when the timer tab is not the one in front.
• The Pomodoro technique, 25/5, and where the numbers came from — the work/break cycle behind the ?pomodoro mode, useful for revision sessions.
• Pomodoro vs timeboxing vs flowtime — choosing an interval structure for study periods rather than for single activities.
• Online stopwatch with lap times — count-up mode with splits, for practicals, PE and anything you time rather than limit.