csTimer: a speedcubing timer that runs in the browser

Three deployments of one codebase

csTimer is described as a professional speedcubing and training timer, and the first thing the README explains is its release model, which is unusual and worth understanding before you install anything.

There are three sites. The main version at cstimer.net, the latest version at cstimer.net/new/, and the source version at cstimer.net/src/. The latest and source versions always match the master branch of the repository, while the main version always matches the released branch.

The update policy follows from that. New features are implemented first in the latest version. After testing for several days, the main version is updated if appropriate, which depends on user feedback for the new function or the update.

So the workflow is that master is a development branch, the new site is that branch deployed for people to try, and the main site is the stable deployment that gets promoted from it. A user who wants the current release uses the main site, a developer or an early adopter watches the new site, and the source site is the same code as the repository for anyone who wants to run it themselves.

There is a practical note attached to all of this. It is preferred to use the HTTPS protocol to visit csTimer. Although HTTP is available, some functions might not work correctly, such as the stackmat timer, WCA login, and similar. Those are exactly the features that talk to a device or to an external identity service, so the reason is easy to infer.

The repository is not archived and the last push was on 2026-09-07, so the project is being worked on, and it has no GitHub releases, since the deployments are the releases.

What the source tree reveals about the scope

The Makefile is where the size of this project becomes clear, because it lists every source file the build compiles.

The build itself is the Google Closure Compiler.

compile = java -jar $(closure) --use_types_for_optimization --language_out STABLE --charset UTF-8 --strict_mode_input
isolation = --isolation_mode IIFE
advanced = -O ADVANCED

So the JavaScript is type checked in strict mode, compiled in stable language mode with type based optimisation, and minified with advanced optimisations. The isolation mode wraps the output in an immediately invoked function, and the compiler runs from a jar in the lib/ directory.

The file list is the feature list, and it is a long one. Under lib/ there are the general utilities, a SHA-256 implementation, the Isaac random number generator, maths and group libraries, a 3D geometry library, the pattern database for the 3x3, a binary search tree, an SQLite file wrapper, a TD converter, the LZ string compression, a min2phase solver, cube utilities and a puzzle factory. The scramble/ directory holds one file per puzzle, from 2x2x2 through the 3x3, 4x4, the clock, the megaminx, the pyraminx, the skewb, the square one, the gear cube and several exotic ones. The solver/ directory has the FTO and megaminx solvers. The stats/ directory has the time statistics, the general statistics, the statistics tool, the trend view, the distribution, the huge statistics, the delay statistics, the reconstituting code, the training statistics. The tools/ directory covers the cross, the Roux method, the group theory solver, the Thistlethwaite method, the image tools, the metronome, the online comparison, the battle tool and the Bluetooth utilities. And under timer/ there are the timer itself plus the input, stackmat, bluetooth timer, and virtual timer modules.

That is a full competitive cubing tool, not a stopwatch.

Where the data lives, and how to keep it

The data storage section is the one to read carefully, because it defines what happens to your history.

All data, including settings and session data, is stored in the user browser's storage. More specifically, all settings are stored in localStorage, while session data, except session metadata, are stored in indexedDB or localStorage if indexedDB is not available.

The consequence follows immediately. All data will be lost if you clear browser cache.

The mitigation is the export function, which exports and imports all your data to and from a file, csTimer's server, or Google storage. So the model is that the browser is the database and the export is the backup, and a user who clears their cache without exporting loses everything.

That design has a rationale. A server-free timer needs no account, no sync, no backend, and it works offline, which is what a cuber at a competition table with patchy connectivity actually needs. The cost is that the data is one cache clear away from gone, and that is a deliberate trade rather than an oversight.

The section on data imported to csTimer's server and Google storage adds a safety net for the upload path. After a specific commit, you can download data that was uploaded before the latest one, which the README says might be useful for a mis-uploading. The retention is limited: for Google Storage, csTimer keeps the 10 latest uploaded data, and for csTimer's own server, 10 or more of the latest uploaded data are kept, with the explanation that the author will keep 10 latest uploaded data while others might be deleted due to limited disk resource.

Ten versions of your history is not much, and it is a small but real reason to export to a file rather than rely on the cloud copy.

The progressive web app and the module package

Two smaller features are worth knowing about because they change how you use the tool.

The first is that csTimer works as a native app on mobile devices through progressive web apps. When you open it in Chrome or another modern browser on a phone, it offers to add csTimer to the home screen, and then it runs as a native app that also works without network access.

That offline capability is a direct consequence of the storage design. If the data is in the browser and the code is a progressive web app with a service worker, then the whole timer is a local artefact. A cuber at a competition can install it once and never think about connectivity again.

The second is that some functions of csTimer are exposed as an npm package called cstimer_module, after a specific commit. The README gives the example of amounts of scrambles, and says to refer to npm for specific usage, with problems to be raised as issues in this project.

So the scramble generators, which are the part of a cubing timer that other software might want, are available as a package rather than only through the web interface.

The third detail is about deployment rather than use. Some functions of csTimer might not work properly for domains other than cstimer.net, especially the online-based export and import functions, because of callback address verification. If you want csTimer to work as part of your own website, the recommendation is to use an iframe.

The callback verification is a security measure, and the advice to use an iframe is the workaround that keeps the verification working while embedding the timer. Anyone planning to put the timer on their own site needs to know that before they start.

Where csTimer is the wrong choice

The first limitation is the storage model, and it is the one that will bite. A cuber with years of session history, personal bests and a detailed statistics record has that history in one browser profile, and clearing the cache, switching browser, or moving to a different machine means starting again unless the export was used.

The second is that the online backup is not a backup in the usual sense. Ten versions on the server and ten on Google storage, with older ones possibly deleted for disk reasons, means the cloud copy is a convenience for recovering a mis-upload rather than an archive.

The third is the deployment restriction. A third-party domain hosting the timer will have problems with the online export and import because of the callback address verification, and the recommended workaround is an iframe, which is an awkward way to embed an application and means the site owner is embedding someone else's application rather than integrating with it.

The fourth is the scope for non-cubing uses. The tool is built for the cube, with a scramble generator per puzzle and a statistics model built around solve times. The training side is there, with training statistics and the reconstituting code, but the tool is not a general interval timer with a data export, and using it as one means fighting the cubing-shaped assumptions in the statistics.

The fifth is that the tool is browser-based with no native desktop application. A cuber who wants a timer that starts with a keypress on a dedicated stackmat without a browser in the path is served by the stackmat support, which the README notes needs HTTPS to work correctly, but the app is still a web page.

csTimer compared with a native speedcubing timer and with a generic interval timer

The comparison with a native speedcubing timer, the kind with a dedicated device and a physical display, is the clearest one because it is a different instrument. A native timer has no input latency worth measuring, no browser in the path, and it starts on the sensor rather than on a key. csTimer counters that with the hardware support, the stackmat module under timer/, the Bluetooth timer module and the virtual timer, and with the fact that the timer is the same page for everyone so a result is comparable between cubers.

The difference in approach is that a native timer measures one puzzle, while csTimer is a training platform. The statistics layer is the part a native timer does not have at all, and it is substantial, with the trend view, the distribution, the huge statistics, the delay statistics and the training statistics. The metronome and the online comparison tools sit alongside them.

The comparison with a generic interval timer is the one for a user who is not cubing. Any interval timer with a CSV export would do the timing, and would store the data in a file that survives anything. csTimer is worth it when you want the scramble, the per-puzzle breakdown and the statistical analysis of your times, and it is not worth it when you want a stopwatch.

The fourth comparison is with a hosted web timer from a different vendor. The difference in approach is ownership of the data, since a hosted service keeps your history on someone else's server, while csTimer keeps it in your browser and lets you take it to a file at any time.

Licence, translation and what to check before you start timing

The licence field on the repository records GPL-3.0, with a LICENSE file at the root. GPL is a strong copyleft licence, and for a tool that people run from a website rather than distribute, the practical effect is mostly on anyone who wants to host their own modified copy, which is precisely what the third-party deployment section describes.

The project is not archived and the last push was on 2026-09-07, so it is being maintained, and the recent releases section says there are no GitHub releases, which matches the branch based deployment model described earlier.

Translation is handled on Crowdin, with a badge linking to the project page. If your language is not on the list, the README asks you to contact the author and it will be added. That is a small sign of a maintained project with an active user base, since a timer for a global community has a translation surface that most software does not.

Four things to check before you start timing.

Whether you will use the main site or the new site. The main site is the stable one, and the new site has the features that have been in testing for a few days, which is where you find out what is coming.

That you use HTTPS, because the README says some functions such as the stackmat timer and WCA login might not work correctly over plain HTTP.

That you export your data at least once in a while, to a file rather than only to the server, given that the server keeps ten versions and the rest may be deleted.

And whether you want the app on your phone, which is a progressive web app install from the browser and then works without a network connection.

Editorial conclusion

csTimer suits a speedcuber or a cubing trainer who wants a timer with per-puzzle scrambles, session statistics and hardware timer support, and who will accept that their history lives in the browser. It is the wrong tool if you need your data to survive a cleared browser profile without thinking about it, because the README says everything is lost when you clear the cache, and it is the wrong choice if you want a native desktop application. Before relying on the online export, use the export function to keep a file copy, since the README explains that uploaded data is kept only for a limited number of versions.

Frequently asked questions

Official sources

1. cs0x7f/cstimer on GitHub
2. Issues
3. License: GPL-3.0
4. README