No — not in the file you get out. Across 55 conversions run today with two and three tabs going at once, every single result was byte-identical to the same photo converted alone. What changes is how long you wait: the tab you are not looking at loses, badly.
Short answer: two tabs do not corrupt each other's output, do not share a queue, and do not overwrite each other's result. They do compete for the CPU, and the tab you are looking at wins. With two 12-megapixel photos converting at the same time on this machine, the visible tab finished in 4,940 ms and 4,374 ms while the hidden one took 10,180 ms and 8,018 ms. Both produced the same 3,177,680-byte JPG.
The pages share nothing. The live page's HTML today is 14,505 bytes and contains 0 mentions of BroadcastChannel, SharedWorker, postMessage or serviceWorker, and 0 mentions of localStorage, sessionStorage, indexedDB or caches. At runtime, all three tabs reported localStorage.length of 0, an empty IndexedDB database list and an empty Cache API list.
How I measured it: today, in Chrome 154.0.8037.98 (headless, Windows, window 1,280 × 900) against the live page, driving real tabs over the DevTools protocol. Every conversion was a real file handed to the real upload input; every output was hashed in the page with SHA-256. Two source photos: the site's 41,465-byte sample and an 11,084,868-byte, 4,032 × 3,024 file.
Across the whole day — solo baselines, two tabs at once, three tabs at once, background tabs, and the cross-tab probes — I ran 55 conversions. They produced exactly three different files, and each one is just a photo at a quality setting:
| Input | Quality | Output | SHA-256 | Times seen |
|---|---|---|---|---|
| 41,465 B, 700 × 476 | 0.85 | 38,078 B | 93859de257dc44a7… | every small-photo conversion |
| 41,465 B, 700 × 476 | 0.95 | 57,617 B | de678d5206fb5ce2… | once (the quality-isolation probe) |
| 11,084,868 B, 4,032 × 3,024 | 0.85 | 3,177,680 B | 56ee525f012aa19f… | every 12-megapixel conversion |
The 38,078-byte and 3,177,680-byte hashes are the ones this site has recorded for those two photos on other days and in other measurements. Concurrency did not add a fourth file. There was no case — none — where a conversion that ran alongside another one came out a different size, a different dimension, or a different hash.
That also holds for the boring failure modes: no error box appeared in any concurrent run, and the spinner stopped normally every time.
I probed this four ways rather than trusting the source scan alone.
Quality is per tab. I set tab one to 0.95 and left tab two alone: tab one's quality menu read 0.95, tab two's still read 0.85, and tab one's next conversion really did use 0.95 — it came out at 57,617 bytes instead of 38,078. Tab two was untouched.
The result area is per tab. I snapshotted tab two's state before tab one converted anything and again afterwards: identical download name, identical file label, identical quality, results panel hidden, error panel hidden, error text empty. What tab one was doing never showed up in tab two.
Storage is shared by the browser, but the site keeps nothing in it. This one has a wrinkle worth stating plainly. When I wrote a key into localStorage from tab one, tab two could read it back — that is normal browser behaviour for a shared origin, not something the site does. What matters is that the site itself stored 0 keys, so there is no cross-tab state of its own to get confused. I removed the probe key afterwards and tab two saw it go.
The JPG blob does cross tabs. Tab two fetched tab one's blob: URL successfully: HTTP 200, 38,078 bytes, image/jpeg, and it loaded as a 700 × 476 image. So a finished result is reachable from another tab on the same site. It is still only reachable from that origin, and it dies with the tab that made it — I could not read it from a fresh tab opened after the original was closed, but I did not measure that case today, so I am not going to put a number on it.
Here is every two-tab run. In Chrome, the tab created most recently starts as the visible one, so tab one was the hidden one and tab two was the visible one throughout — I confirmed that by reading document.visibilityState in a clean session.
| What the two tabs converted | Hidden tab | Visible tab | Overlap |
|---|---|---|---|
| Two small photos, together | 1,230 ms | 715 ms | 699 ms |
| Two small photos, 200 ms apart | 1,082 ms | 154 ms | 154 ms |
| Two 12-megapixel photos, together | 10,180 ms | 4,940 ms | 4,644 ms |
| Two 12-megapixel photos, together (again) | 8,018 ms | 4,374 ms | 4,203 ms |
| 12-megapixel + small photo | 6,338 ms | 160 ms | 89 ms |
| 12-megapixel + small photo, 1,000 ms apart | 6,365 ms | 122 ms | 122 ms |
The overlap column is how long both conversions were genuinely running at the same instant — proof that they were concurrent rather than queued. On the 12-megapixel pairs that was more than four seconds of real overlap.
So: small photos barely notice each other. A small photo converting while a 12-megapixel one grinds away finished in 160 ms and 122 ms, against 105 to 163 ms when it had the machine to itself. Big photos notice a lot: a 12-megapixel conversion that takes roughly four to five seconds alone took 8,018 to 10,180 ms when the tab was hidden and another one was running.
My first reading of the table above was "background tabs are slow". That turned out to be wrong, and the controlled run is the most useful thing I measured today. I converted a 12-megapixel photo in one tab with nothing else happening, alternating whether that tab was in front or behind:
| Tab state | Conversion 1 | Conversion 2 | Conversion 3 | Output |
|---|---|---|---|---|
| Hidden (another tab in front) | 8,130 ms | 3,366 ms | 5,202 ms | 3,177,680 B |
| Visible (this tab in front) | 3,836 ms | 4,782 ms | 5,176 ms | 3,177,680 B |
The two rows overlap completely. Hiding a tab on its own cost nothing measurable. The penalty only appears when the CPU is contested, and then it goes to the tab you are looking at. I am reporting that as an observation rather than explaining it — I did not measure Chrome's process priorities, and this is a two-core Windows machine, so the size of the gap will be different on yours.
What is safe to say is that the hidden tab always finished. In a separate pair of runs with one tab in front and one behind, the hidden one completed in 5,788 ms and 5,847 ms, both times producing the usual 3,177,680 bytes. Nothing was cancelled, nothing timed out.
With three 12-megapixel conversions going simultaneously, the visible tab kept nearly all of its speed and the two hidden ones paid for it:
| Round | Tab one (visible) | Tab two (hidden) | Tab three (hidden) |
|---|---|---|---|
| 1 | 4,788 ms | 21,738 ms | 21,957 ms |
| 2 | 4,470 ms | 14,690 ms | 14,322 ms |
All six came out at 3,177,680 bytes with the same hash. So the queue does not break under load — it just gets slower in a way that is very unevenly distributed. If you are batch-converting and want the fastest wall-clock time, keep one tab in front and do not switch away from it.
Both tabs downloaded fine. Two rounds of pressing download in both tabs at the same moment landed four files — f_a_r1.jpg, f_b_r1.jpg, f_a_r2.jpg, f_b_r2.jpg — each 38,078 bytes, each named after the file its own tab had been given.
The second tab does not re-download the decoder. The first tab in a fresh browser made 7 requests totalling 880,616 bytes, of which 691,111 bytes came from this site and 680,000 of those were the decoder script. The second tab made 6 requests totalling 5,974 bytes, and the decoder came from disk cache at 0 bytes transferred. A third tab cost 5,052 bytes. Time until the converter was usable: 1,572 ms, then 653 ms, then 308 ms.
I did not measure memory across tabs today, so I will not claim anything about it — the 50-photo memory measurement covers a single tab only.
Not in anything I ran: 55 conversions today produced 3 distinct files, and each matched the hash for its photo and quality setting. Every concurrent conversion's output was identical to the same photo converted alone — see the determinism measurement for the single-tab hashes.
No. I snapshotted tab two before and after tab one converted, and the download name, file label, quality setting, preview dimensions and panel visibility were all identical. The only thing that genuinely crosses between tabs is the finished blob URL, and nothing in the page fetches one from another tab.
On this two-core machine, no — the pair took longer than either one alone, and the time was lopsided. Two 12-megapixel photos at once finished at 10,180 ms and 4,940 ms, so the wall clock was set by the slower tab. One after the other would have been roughly four to five seconds each.
Yes, every time. Hidden tabs completed in 5,788 ms and 5,847 ms with two tabs, and in 21,738 ms and 21,957 ms with three, always with the correct 3,177,680 bytes. That is consistent with the interrupted-conversion measurement, where switching away mid-conversion also did not break anything.
Not measurably. With nothing else running, hidden runs took 8,130 / 3,366 / 5,202 ms and visible ones 3,836 / 4,782 / 5,176 ms — the ranges overlap. The slowdown only shows up when another conversion is competing for the CPU.
That is a different and worse problem: two files given to one tab decode concurrently, and the last one to finish overwrites the name of the one that finished first. That is the second-file-midway measurement. Two separate tabs do not have that bug.
I only measured Chrome 154 on Windows today, in a 1,280 × 900 headless window. I have no numbers from Firefox, Safari, a phone, or more than three tabs, and I did not measure two separate windows instead of two tabs. Treat the timing as specific to this machine; the byte-identical output is the part I would expect to hold everywhere.
No. First tab: 680,000 bytes for the decoder over the network. Second tab: 0, served from disk cache. Third tab: also 0. Total page cost dropped from 880,616 bytes to 5,974 to 5,052.
Try it: open the converter in two tabs, drop one photo into each, and compare the two JPGs — same bytes, different clocks.
First published: 8 October 2026