Red Apis And Feature Detection
Some browser capabilities will never exist on the open web -- not because they are too new, but because they would be too dangerous. Here is how the standards pipeline works and how to detect what is actually available.
Some capabilities will never be available in a regular browser tab. Not because the technology doesn't exist. Because any website could silently access them.
That is the security argument for red APIs -- and it is a valid one.
The Fourth Tier
The maturity tiers covered earlier in this series described three levels: green, light-green, and experimental. The origin trials post covered the experimental layer specifically. The fourth tier has no polite name -- it is simply capabilities that are not implemented anywhere, with no experimental version and no clear path to shipping.
Red APIs fall into two buckets. The first is "not yet" -- someone wants to build this, discussions are happening, but no browser has committed to implementing it. This might ship eventually, or it might not.
The second is "probably never." Some capabilities give a website too much power over a user's device or data to expose without explicit trust. A website that can silently vibrate your phone or read your battery status might seem harmless. A website that can silently talk to any Bluetooth device in range, read files from your filesystem without a dialog, or enumerate nearby hardware -- that is a much bigger risk. Some capabilities stay off the table because the security model for a URL-based context does not support them.
If You Need a Red API
If your product genuinely requires a capability the open web won't provide, you have two real options.
On desktop, you can embed your web app in a native container that bridges JavaScript to platform APIs. Electron is the most common choice -- it is how VS Code, Slack, and Figma work. The web layer runs in a Chromium shell that grants access to APIs that a browser tab never would.
On mobile, the equivalent path is packaging your web app as a native app through tools like Capacitor (from the Ionic team) or the older Cordova/PhoneGap approach. You write web code, but ship it through an app store wrapper that can request native permissions.
A third option is a browser extension -- but extensions are multi-origin by design. They attach to every site in the browser, not just yours. That makes them a poor fit for capabilities you want to scope to a single web app.
These options all require leaving the URL behind. A user has to install something. The trade-off is explicit.
How APIs Actually Get Standardized
The standards process is slower and more political than most developers expect.
It typically starts as a GitHub proposal. Anyone can write one. But a proposal without a browser vendor behind it goes nowhere -- one or more browser vendors need to say "this looks worth building" and actually commit engineering resources.
Once a browser commits, the API enters the experimental phase. Flags get enabled, origin trials open, real-world feedback flows back. This phase can last months or years.
After enough feedback, the proposal moves to W3C review. The W3C sets official web standards. For an API to become a formal recommendation, multiple vendors need to agree -- Chrome, Firefox, and Safari all need to say yes.
ExpandThe Web API Standards Pipeline
Multi-vendor consensus is where things get interesting.
Apple took seven years to ship Web Push notifications -- a feature Chrome and Firefox had supported for years. There was no technical blocker. It was a product decision. There are other APIs where Apple has explicitly said it will not implement them at all.
When W3C review ends without consensus, three outcomes are possible. The best case is that enough vendors agree and the API ships as a stable standard. The second case: the API gets rejected by W3C, but Chrome ships it anyway. Those APIs work -- in Chrome only -- without ever becoming a formal standard. The third case is that the API is dropped entirely.
This matters for how you evaluate APIs. Checking "is this in Chrome" is not the same as checking "is this a web standard." Some Chromium-only APIs are in a grey zone where Chrome supports something the W3C never will.
Detecting What Is Actually Available
There is no navigator.supports() API. No formal way to pass a capability name and get a yes or no back.
What exists instead is simpler and surprisingly reliable: most browser APIs inject a constructor, a function, or a property into a globally accessible object -- usually navigator or window. To check if an API is available, you check if that property exists.
// Web Bluetooth -- light-green, Chromium only
if ('bluetooth' in navigator) {
showBluetoothControls();
}
// Web Serial -- light-green, Chromium only
if ('serial' in navigator) {
showSerialConnectButton();
}
// Geolocation -- green, available everywhere
if ('geolocation' in navigator) {
enableLocationFeatures();
}
// Web NFC -- light-green, Android Chrome only
if ('NDEFReader' in window) {
showNFCScanOption();
}This tells you the API is present. It does not tell you it will succeed -- the user can still deny permission, or the hardware might not be there. But it lets you gate the UI correctly so that users without the capability see a clean path rather than a broken one.
Write this check before rendering capability-dependent UI, not after. The pattern is: detect, then decide whether to show the control at all.
What the Rest of This Series Uses
Every capability covered from here on falls somewhere on this maturity spectrum. Sensors, Geolocation, Bluetooth, NFC, Web Audio -- each has a tier, and that tier determines whether you need feature detection, a fallback plan, or both.
For the sections ahead, the focus is green and light-green APIs -- the ones you can actually ship today. Anything experimental or red gets flagged explicitly.
Before touching any of them, there's one practical skill left to cover: knowing which tools to reach for when you need to check support, read a spec, or understand what a browser has actually shipped.
The Essentials
- Red APIs are capabilities the web does not expose because they would be too dangerous in a URL context. The workaround is a native wrapper -- Electron on desktop, Capacitor or Cordova on mobile.
- The standards pipeline goes: GitHub proposal → browser vendor interest → experimental → W3C review → stable, Chrome-only, or dropped. Apple being years late (or outright refusing) is a pattern, not an exception.
- Feature detection is just a property check:
'bluetooth' in navigator,'serial' in navigator,'NDEFReader' in window. Gate capability-dependent UI behind this check before rendering.
Further Reading and Watching
- Intro to Web Standards: What/Who is the W3C -- Lola Odelola -- clear explanation of how the W3C process works and why multi-vendor consensus matters
- web.dev -- Fugu API Tracker -- live tracking dashboard for all web capability proposals across green, experimental, and red tiers
Keep reading