Which browsers it runs in, and what each one costs you
It runs in Safari, Chrome, Edge and Firefox on macOS, Windows, Linux and ChromeOS. The RAW decoder needs Chrome 95, Firefox 131 or Safari 18.4 or later; JPEG, PNG, WebP and TIFF stack in any current browser. Phones and tablets are refused before a byte is decoded. Every number on this page is read from the engine when the page is built, so the figure you see here and the refusal you would see in the tool cannot disagree.
How much memory each browser gives the tab
A browser tab is not a desktop application. It gets a slice of the machine, the size of the slice depends on which engine is running, and when a tab grows past what the engine will tolerate it is killed — on iOS without an error, an event, or a chance to save anything. So this tool works from a stated budget per engine rather than from hope, and before a run starts it states the estimated peak the sequence will need against that budget. If the estimate does not fit, the run is refused with the two numbers side by side rather than failing forty minutes in.
| Browser | Engine key | Committed budget | Largest single buffer | Note |
|---|---|---|---|---|
| Chrome, Edge and other Chromium browsers | chromium | 3.0 GB | 1.5 GB | |
| Firefox | firefox | 3.0 GB | 2.0 GB | |
| Safari | webkit | 2.5 GB | 2.0 GB | JPEG and WebP decode on the page rather than in the worker |
| Any phone or tablet | mobile | 0.5 GB | 0.5 GB | hard cap: refused before a byte is decoded |
Scroll the table sideways for the remaining columns.
“Committed budget” is the most the engine will hold at once across the whole run. “Largest single buffer” is the biggest piece it will ask the browser for in one allocation, because an engine that will happily give you three gigabytes in pieces can still refuse two in one. The phone row is a hard cap rather than a budget: a phone that says it is Chrome is still a phone, and half a gigabyte is where the kernel starts killing tabs.
What each browser can and cannot do
The rows below are runtime facts: the tool checks for each capability when it needs it and, where one is missing, says so by name and takes the slower or plainer path. Nothing here is a guess about a browser; it is what the code does when the capability is absent.
| Chrome, Edge | Firefox | Safari | Phones, tablets | |
|---|---|---|---|---|
| RAW decoder | 95 and later | 131 and later | 18.4 and later | refused |
| Hand over a whole folder | yes | no — select the files | no — select the files | refused |
| Save straight to a file | yes | no — ordinary download | no — ordinary download | — |
| JPEG and WebP decode | in the worker | in the worker | on the page, slower | — |
| Learned line detector | WebGPU when present, else CPU | WebGPU when present, else CPU | WebGPU in Safari 26, else CPU | — |
| Install | Install, from the menu | bookmark | Add to Dock, Safari 17 and later | not offered |
Scroll the table sideways for the remaining columns.
- RAW decoder
- The decoder is WebAssembly built with native exception handling, and the versions in the row are the first releases that run it. An older browser is told so by name, and everything else on the page still works: JPEG, PNG, WebP and TIFF stack in any current browser.
- Hand over a whole folder
- Chromium browsers can be handed a folder; the tool then reads what it needs when it needs it. Firefox and Safari do not offer that, so you select the files instead — a multi-select of a night’s frames works the same way once they are in.
- Save straight to a file
- In Chromium browsers the finished picture can be written straight to a file you choose, which matters for a 16-bit result of several hundred megabytes. Elsewhere it is assembled in memory and downloaded the ordinary way; the control is hidden rather than shown and refused.
- JPEG and WebP decode
- Safari’s worker can decode a bitmap but cannot paint one, so JPEG and WebP frames are handed to the page one at a time, painted into a detached canvas, read back and returned. Nothing is copied twice and no frame is kept, but it is slower than the in-worker path. Camera RAW does not go through this and is unaffected.
- Learned line detector
- The learned aircraft-and-satellite detector runs on WebGPU where the browser offers it and on the CPU where it does not, with the reason named. Safari 26 ships WebGPU on by default; earlier Safari takes the CPU path. WebKit’s Safari 26 release notes are the source for that.
What is proven where, and what is not
- Chromium, Firefox and WebKit, every format. The release gate drives the built site behind its own security policy, through the real worker, over every advertised raster format and every supported RAW, in all three engines. That is a Playwright WebKit build, not a boxed Safari.
- Real Safari 26.5 on macOS 26.5, Apple silicon. A recorded run rendered the Mac comparison page and completed a twelve-frame synthetic Star-trails sample in system Safari. It proves the journey completes; it does not prove speed, and the frames were generated, not camera RAW. What has actually been proven on a Mac.
- Not proven, and not claimed. Edge is covered only as Chromium, never tested by name. No camera-RAW night has been timed in real Safari on this site; no such run has been timed, and until one is recorded this page will keep saying so. No phone or tablet is claimed: the phone cap is a refusal before the first byte is decoded, and that is deliberate.
Installing it
There is nothing to download. What the browsers call installing is a window and an icon for this site:
- Safari on macOS
- Safari 17 and later: File › Add to Dock. The site opens in its own window with the name and icon this site declares, and appears in the Dock like an application.
- Chrome and Edge
- Install Star Trail Stacker from the menu in the address bar. There is no install banner, because this site runs no service worker, and the banner is what a service worker buys.
- Firefox
- Bookmark it. Firefox does not offer desktop installation of web applications. MDN’s installability guide lists which browsers do.
What you get is still the live site. There is no offline mode: the installed window needs a connection to load, exactly as the tab does. That follows from a decision made before it was a technical one — this site keeps no storage in your browser at all, no cookie, no cache, no worker, so there is nothing that could hold a copy of the tool for later. The data boundary says what leaves the tab, which is nothing.
Where the refusals come from
Every “cannot” on this page is a refusal the tool shows by name at the moment it applies, with the same constants behind it. If the tool tells you a browser is too old for the RAW decoder, the versions it names are the ones in the table above, read from the same place. Every refusal it can put on your screen, and what each one means.