Will your Chrome extension work in Safari?
Paste your manifest.json and find out in five seconds which APIs carry over, which need a redesign, and which don’t exist in Safari at all. The checks come from the checklist I use on paid port assessments. Everything runs in your browser; nothing is uploaded.
What this checks, and what it can’t
The manifest declares what your extension is allowed to do, so it reveals the structural port risks: blocking webRequest, persistent backgrounds, page overrides, and APIs Safari doesn’t implement. What it can’t see is your code: background lifecycle assumptions, API behavior differences, storage timing, and everything iOS. That half is what the paid port assessment covers, and why this tool is free.
Questions clients ask
Is my manifest uploaded anywhere?
No. The analysis is JavaScript running in your browser tab. There is no server, no storage, and no analytics on the manifest contents.
My extension passed. Does that mean the port is easy?
It means the manifest has no structural blockers. That is a signal, not a guarantee. Most port pain lives in code the manifest can’t show: background lifecycle, API behavior differences, and App Store review. That’s what the one-week assessment covers.
It flagged blockers. Is the port dead?
Usually not. Most blockers have Safari-shaped redesigns: blocking webRequest becomes declarativeNetRequest, and chrome.identity becomes web-based OAuth. The question is cost, which is what the assessment answers with a fixed bid.