screenfull: a 0.7 kB wrapper for the Fullscreen API that is finished on purpose

The prefix branching screenfull removes

The Fullscreen API reached browsers at different times and under different names, so calling it directly means writing the same fallback chain on every project. The README shows the vanilla version: assign document.fullscreenEnabled from itself, then document.mozFullScreenEnabled, then document.documentElement.webkitRequestFullScreen; then a requestFullscreen function that tries element.requestFullscreen, falls back to element.mozRequestFullScreen, then to element.webkitRequestFullScreen with Element.ALLOW_KEYBOARD_INPUT. The README adds, in its own words, "This is not even entirely comprehensive. There's more." screenfull collapses all of that into one import and a boolean check, which is the whole pitch. It is for front-end developers building a viewer, a slide deck, a video surface or a kiosk page who want fullscreen to behave the same in Chrome, Firefox and Safari without maintaining a prefix table. It is not a UI library: there is no button, no styling, no keyboard shortcut. You supply the trigger and the element.

How the wrapper is put together

The package ships exactly two files to npm, index.js and index.d.ts, per the files field in package.json, and the repository root holds index.html as the demo page plus index.test-d.ts for type assertions. That is a small surface for a module whose job is detection. The public API is deliberately flat: request(element, options?), exit(), toggle(element, options?), on(event, function), off(event, function), plus the onchange and onerror aliases; and the read-only properties isFullscreen, element, isEnabled and raw. The raw property is the escape hatch, exposing the prefixed internals the module resolved at load time: requestFullscreen, exitFullscreen, fullscreenElement, fullscreenEnabled, fullscreenchange and fullscreenerror. Everything else is a thin layer over those six names. The events are only 'change' and 'error', so any state you keep has to be derived from screenfull.isFullscreen inside a change handler rather than from a richer event model. request, exit and toggle return promises that resolve after the element enters or exits fullscreen, which means you can sequence work after the transition instead of guessing with a timeout.

Installing screenfull and wiring a first toggle

The README gives one install command and notes the package is 0.7 kB gzipped. It is ESM only: package.json sets "type": "module" and exports ./index.js, and the README warns that if you cannot use ESM or need older browsers without transpilation, you should use version 5.2.0 instead. The engines field requires Node ^14.13.1 or >=16.0.0 for the tooling around it.

npm install screenfull

A first real use is a button that toggles an element and logs the result. Import the default export, guard on isEnabled, and pass the DOM node to toggle. The README's jQuery example does the same thing with $('#target')[0]; plain DOM is simpler.

import screenfull from 'screenfull';

const target = document.getElementById('target');

document.getElementById('button').addEventListener('click', () => {
	if (screenfull.isEnabled) {
		screenfull.toggle(target);
	}
});

To react to the browser leaving fullscreen, for example when the user presses Escape, subscribe to change and read isFullscreen. Note that off takes the same function reference you registered, so keep a named handler rather than an inline arrow.

if (screenfull.isEnabled) {
	screenfull.on('change', () => {
		console.log('Am I fullscreen?', screenfull.isFullscreen ? 'Yes' : 'No');
	});
}

On mobile, request accepts FullscreenOptions, and the README shows {navigationUI: 'hide'} as a way to hide the navigation user interface when fullscreening an element. The README also states that if your page sits inside an iframe you must add allowfullscreen, plus webkitallowfullscreen and mozallowfullscreen, or isEnabled will not be true.

The iPhone gap and other places screenfull is the wrong tool

The README is blunt about the largest limitation: Safari is supported on desktop and iPad, but not on iPhone, and it attributes this to the browser rather than to screenfull. If a meaningful share of your traffic is iPhone, a fullscreen control is simply unavailable there and you need a different presentation strategy, typically a CSS layout that fills the viewport without the Fullscreen API. Two more constraints come from the browser, not the wrapper. The README states that the browser will only enter fullscreen when initiated by user events such as click, touch or key, so any attempt to call request on page load or from a timer will fail, and the error event is where that surfaces. And the FAQ says navigating to a new page while staying fullscreen is not supported for security reasons; the README's suggested workaround is an iframe that fills the screen and navigates internally, which it labels a dirty workaround. If your flow depends on moving between documents under fullscreen, screenfull cannot give you that. Finally, request switches to a new element only if it is a descendant of the currently fullscreened one, which is a constraint worth knowing before you build a multi-panel viewer.

screenfull versus calling requestFullscreen directly

The honest alternative is the vanilla code the README prints side by side with its own: write the prefix chain yourself and call element.requestFullscreen, element.mozRequestFullScreen or element.webkitRequestFullScreen directly. The difference is not capability, since screenfull is a wrapper over exactly those calls, but maintenance. The vanilla version has to be repeated in every codebase, has to be kept in sync as prefixes change, and the README's own sample concedes it is incomplete. Direct calls give you the raw browser behaviour with no abstraction, which matters if you need an option or an event the wrapper does not surface, or if you are already inside a framework that has its own fullscreen directive. Against that, screenfull gives you a single isEnabled check, promise-returning request and exit, and change and error events with matching off removal, for 0.7 kB. If your bundle is ESM-first and you target modern browsers, the wrapper costs less than the code it replaces. If you are transpiling to CommonJS or supporting old browsers without a build step, the README points you at 5.2.0, and at that point the calculation changes.

Maintenance status, licence and the cost of upgrading

The repository is not archived, and its last push was on 2026-09-18, so the project is still receiving commits even though the README declares it feature complete and says no new features will be accepted. The release history tells a different story from the commit log: v6.0.0 landed in November 2021, v6.0.1 in January 2022, and v6.0.2 in June 2022. There has been no tagged release since. Practically, that means the API you read in the README is the API you get, and an upgrade is unlikely to be forced on you by a major version bump. The package is MIT licensed, which permits commercial and private use with the licence and copyright notice retained; that is a statement about the licence text, not legal advice, and if your organisation has policies about bundled dependencies you should check them against the licence file in the repository. The one upgrade cost worth planning for is the ESM boundary: moving from 5.2.0 to 6.x means your build must handle ESM, and the README links to a note on what that implies rather than restating it. If your toolchain cannot, stay on 5.2.0 and accept the older browser support it was written for.

Editorial conclusion

Adopt screenfull if you ship a modern ESM bundle and want request, exit, toggle and change events without writing prefix branches yourself; the package is MIT licensed and its last release was v6.0.2 in 2022. Do not adopt it if you must support iPhone Safari fullscreen, need a CommonJS build, or need to navigate the page while staying fullscreen, since the README states browsers block that for security reasons. Before wiring it in, verify two things in a real browser: that screenfull.isEnabled is true inside any iframe you control, which requires the allowfullscreen attribute, and that a click handler is what calls request, because the browser only enters fullscreen from user events.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sindresorhus/screenfull on GitHub