For years, many projects started with a seemingly simple requirement: “the website must work in every browser.” The problem is that this statement does not define versions, devices, critical features, or what “work” actually means. Teams consequently tend to choose one of two extremes: keeping outdated technology as a precaution or adopting new features without checking whether the audience can use them.
As of August 2026, Baseline provides a clearer vocabulary for that conversation. The initiative summarizes when a web platform feature is available across major browsers and distinguishes between limited, newly interoperable, and widely available capabilities. The official Baseline 2026 page lists the features that have reached the interoperability threshold during the year.
This does not remove the need for testing. It changes the starting point: compatibility can become a documented decision rather than an assumption.
What it actually means for a feature to be Baseline
Baseline evaluates the availability of native HTML, CSS, JavaScript, and web API features across a core browser set. According to the explanation published by MDN Web Docs, there are three main states:
- Limited availability: the feature has not yet been implemented across all the browsers in the core set.
- Newly available: the feature works in current stable versions of the core set but may be missing from older devices or releases.
- Widely available: at least thirty months have passed since interoperability was reached, substantially expanding its practical coverage.
The set includes Safari on macOS and iOS, Chrome on desktop and Android, Firefox on desktop and Android, and Edge on desktop. This creates a shared reference, but it does not represent every browser, embedded device, or application using a WebView component.
During 2026, the list added capabilities such as field-sizing, container style queries, contrast-color(), Trusted Types, and the Navigation API. Their presence in Baseline 2026 means they reached interoperability in the core set during this year; it does not mean that every visitor already has access to them.
A web technology should not be selected merely because it is new or already works in one browser. It should be selected when it delivers a concrete improvement and there is a strategy for people who cannot use it yet.
Why “it works in my browser” is no longer enough
A feature may work perfectly on a developer's computer and fail for a relevant part of the audience. It can also be technically supported while creating difficulties for screen readers, low-performance devices, in-app browsers, or operating systems that no longer receive browser updates.
MDN explicitly notes that Baseline is not a substitute for accessibility, usability, performance, security, or older-device testing. This limitation matters because it prevents teams from treating a compatibility label as a universal guarantee.
For an organization, compatibility should be described in layers:
- Essential actions: reading information, navigating, checking prices, submitting a form, signing in, or completing a purchase.
- Enhanced experience: animations, transitions, advanced controls, or interactions that improve convenience.
- Experimental capabilities: limited-availability features that require detection, an alternative, or controlled testing.
This separation allows a visual enhancement to fail without blocking an inquiry or sale. It is progressive enhancement applied to real business goals.
How to turn Baseline into a project requirement
The decision is not as simple as requiring “Baseline 2026.” Such a recent target might be appropriate for an internal application running on managed devices, but too demanding for a public website serving a diverse audience.
A more responsible process can follow these steps:
- Define the tasks that must never break. Identify forms, payments, authentication, search, and other critical journeys.
- Review first-party data. Analyze the browser versions, operating systems, devices, and WebViews present in actual traffic.
- Select a compatibility target. Baseline Widely available can provide a conservative foundation, while a specific year can establish a verifiable cutoff.
- Classify new features. Decide which ones are essential and which can be optional enhancements.
- Define fallbacks. Use feature detection, fallback styles, or simplified journeys when necessary.
- Automate checks. Integrate the chosen target into development tools and review exceptions throughout the project.
- Test on real devices. Include mobile hardware, keyboard navigation, assistive technologies, and less favorable connections.
The official guide on how to use Baseline with Browserslist explains that teams can declare targets such as baseline widely available, baseline newly available, or a particular year. The configuration can then inform build, analysis, and compatibility-warning tools.
Which target should you choose?
There is no universal answer. The decision depends on who uses the website and the consequences of an incompatibility.
Public websites with broad audiences
Widely available features are a sensible starting point for essential journeys. More recent capabilities can be added as enhancements when a functional alternative exists.
Internal applications and controlled environments
A newer target may be appropriate when the organization manages devices, operating systems, and updates. The minimum supported environment should still be documented.
Products for technical audiences
Teams may be able to move faster, but usage data remains more reliable than assumptions. A specialized audience may still depend on older corporate devices or embedded browsers.
Critical services
Healthcare, finance, government procedures, education, and essential services require a more conservative strategy. Technical compatibility must be complemented by accessibility, security, error tolerance, and specific testing.
A short policy you can apply now
A team can begin with a straightforward policy:
- Essential features will use an agreed Baseline target supported by audience data.
- Limited-availability features will require a fallback or documented justification.
- No compatibility label will replace accessibility, performance, and security testing.
- The target will be reviewed periodically rather than changed informally for each task.
- Exceptions will be recorded to prevent invisible dependencies.
Conclusion: Baseline 2026 is not an instruction to use every new feature introduced this year. It is a tool for discussing compatibility precisely, separating interoperability from real-world coverage, and deciding which risks are acceptable. The next step is to review your site's critical actions, examine available analytics, and document a compatibility target.
If a project needs to renew its technical foundation, Ideasweb can plan and build a website with compatibility, performance, and accessibility requirements defined from the outset.
Does your website rely on outdated technology or behave differently across browsers? We can assess it as part of a web development project and propose a gradual upgrade without disrupting essential features.
