screenfull

screenfull is a tiny (0.7 kB gzipped) wrapper around the browser Fullscreen API that smooths over vendor-prefix differences (requestFullscreen vs mozRequestFullScreen vs webkitRequestFullScreen) so developers can call one consistent API instead of feature-detecting and branching across browser implementations themselves.

Written by Sindre Sorhus, it exposes a single default export with request(), exit(), toggle(), an isFullscreen getter, and a change/error event API, and works on both the whole document and an individual DOM element. The library is explicitly declared feature-complete by its maintainer — it does exactly one thing and isn’t expected to grow further.

What You Get

• screenfull.request(element?) to enter fullscreen for the whole page or a specific element
• screenfull.exit() and screenfull.toggle() for leaving or toggling fullscreen state
• screenfull.isFullscreen and screenfull.isEnabled getters for checking current/available fullscreen state
• A change event fired whenever fullscreen state changes, and an error event for failed fullscreen requests
• Full TypeScript type definitions bundled with the package
• A tiny (0.7 kB gzipped) footprint with zero runtime dependencies

Common Use Cases

• Adding a ‘fullscreen’ button to video players, image galleries, or presentation/kiosk-mode web apps
• Building custom video players that need reliable fullscreen toggling across Chrome, Firefox, and Safari
• Kiosk or dashboard applications that need to enter fullscreen mode on a specific element rather than the whole page
• Any app avoiding hand-rolled vendor-prefix branching for the native Fullscreen API

Under The Hood

Architecture — The entire implementation lives in a single index.js file (160 lines): an internal function map resolves the correct vendor-prefixed method/property names once at module load (checking document.fullscreenEnabled, mozFullScreenEnabled, webkitFullscreenEnabled in order), then the exported screenfull object’s methods (request, exit, toggle) simply delegate to whichever underlying browser method was detected, normalizing return values as Promises regardless of whether the native API is Promise-based or callback-based.

Tech Stack — Zero runtime dependencies, pure vanilla JavaScript, published as an ESM-only package (a deliberate v6 migration point called out prominently in the README, with v5.2.0 recommended for consumers who cannot use ESM or need older browser support without transpilation). TypeScript definitions are hand-authored and shipped alongside the JS.

Code Quality — Testing is limited to xo (opinionated ESLint config) for linting and tsd for validating the TypeScript type definitions against index.test-d.ts — there is no runtime unit test suite, which is a reasonable trade-off given the library’s entire surface area is thin delegation to browser-native APIs that can’t meaningfully be unit-tested outside a real browser. The maintainer has explicitly marked the library feature-complete, so the low recent commit activity reflects stability rather than abandonment.

API Design — The single default-export object with request/exit/toggle/isFullscreen is about as minimal as a wrapper API can get, deliberately mirroring the shape of the native Fullscreen API rather than inventing new abstractions. This makes the learning curve close to zero for anyone who has read one MDN page on fullscreen, while still eliminating the actual pain point (vendor-prefix branching) that motivates using a wrapper at all.