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. On a phone or tablet a night that does not fit at full size is made at a smaller picture size, and the plan beside Start says the size 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.

On this page

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.

What each browser engine is allowed to commit, from the engine’s own budget table
BrowserEngine keyCommitted budgetLargest single bufferNote
Chrome, Edge and other Chromium browserschromium3.0 GB1.5 GB
Firefoxfirefox3.0 GB2.0 GB
Safariwebkit2.5 GB2.0 GBJPEG and WebP decode on the page rather than in the worker
Any phone or tabletmobile0.5 GB0.5 GBhard cap: a night that does not fit is made smaller, and the plan says so before Start; 0.35 GB on a phone that reports 2 GB or less

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.

Capabilities by browser, as the tool detects them
 Chrome, EdgeFirefoxSafariPhones, tablets
RAW decoder95 and later131 and later18.4 and laterrefused
Hand over a whole folderyesno — select the filesno — select the filesrefused
Save straight to a fileyesno — ordinary downloadno — ordinary download—
JPEG and WebP decodein the workerin the workeron the page, slower—
Aircraft and satellite trail cleaning91 and later89 and later16.4 and later—
Learned line detectorWebGPU when present, else CPUWebGPU when present, else CPUWebGPU in Safari 26, else CPU—
InstallInstall, from the menubookmarkAdd to Dock, Safari 17 and laternot 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.
Aircraft and satellite trail cleaning
Trails are cleaned by comparing each frame with its neighbours in WebAssembly that uses SIMD instructions, so it needs Chrome 91, Firefox 89 or Safari 16.4 or later. In an older browser the night is still stacked, with the older line search cleaning trails instead, and the result says which one ran. The cleaner’s extra memory is part of the estimate the tool shows before a run. On a phone or tablet the cleaner works in smaller pieces to fit; where even that does not fit, the plan beside Start says the simpler cleaning will run, and why.
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. Phones and tablets have so far been tested only by imitating an iPhone on a computer: under the page's own phone budget a 60-photo, 6-megapixel night ran at full size with the economy cleaner. No run on a physical iPhone or iPad has been measured yet, and the phone budget stays at its strict level until one is.

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, where supported. Installation gives the live site its own window; it does not make the tool work offline.
iPhone and iPad notifications
Add the site to your Home Screen from the browser’s Share menu, open it there, then choose Enable browser alerts on the alerts page. Notification support is checked on the device. Email forecasts work in a normal tab.
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 offline copy of itself. An explicitly enabled aurora notification worker only receives push messages and opens their link; it has no fetch handler, cache or photo processing. The data boundary says what leaves the tab; your photographs never do.

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.

Read on