Fullscreen Test - Real Fullscreen API

Actually enter true browser fullscreen mode and confirm your browser genuinely supports it, along with the events that detect entering and exiting.

What Is a Fullscreen Test?

A fullscreen test checks whether your browser can actually place part of a web page into genuine Fullscreen API mode, not merely stretch a panel with CSS. This tool asks the browser to enter fullscreen only after your click, then observes the reported fullscreen element and actual change events. It also checks whether the document reports that fullscreen is enabled, and whether a supported Permissions Policy interface says the feature is allowed or blocked.

How to Use the Fullscreen Test

Open the direct test page: visit the tool in a normal browser tab rather than an embedded preview. Check the Request method and Policy / eligibility indicators. EXPOSED means the browser has an API method, not that fullscreen has already worked.
Test the display area: click ENTER TEST AREA. The patterned preview should take over the display using the real Fullscreen API. This must be a user-initiated click; the tool never starts fullscreen on page load.
Check the confirmation: look for Fullscreen entry verified and an increased Verified transitions counter. These mean the page observed a browser fullscreen change event and the correct fullscreen state, not just a successful button click.
Exit safely: use EXIT FULLSCREEN inside the test area or press Esc (or the device's supported browser exit gesture). After exit, the counter should advance again if a corresponding fullscreen change event occurs.
Try the alternate mode: click ENTER WHOLE TOOL to fullscreen the entire diagnostic widget rather than only the patterned area. The test controls remain within that fullscreen view.
Review and export: read the event history and browser context hints. Use RE-CHECK SUPPORT, RESET COUNTERS, COPY SUMMARY or DOWNLOAD JSON. Reset does not automatically exit fullscreen; it only clears this page's diagnostic counters.

How It Works

The tool calls Element.requestFullscreen(), with older prefixed methods as fallbacks where exposed, from the original click handler so it retains the user activation that browsers require. It listens for fullscreenchange and supported prefixed events on the document and compares the actual fullscreen element before counting a state transition. Some legacy browser methods do not return Promises, so this tool checks before attaching Promise rejection handling.

Where exposed, document.fullscreenEnabled and document.permissionsPolicy.allowsFeature('fullscreen') (or a legacy policy interface) provide additional eligibility hints. These hints do not prove that a fullscreen request will succeed. The tool also distinguishes raw change events from distinct observed state transitions to avoid double-counting browsers that fire both standard and prefixed events. It does not make an automatic fullscreen request or use synthetic success values.

Understanding Your Results

Fullscreen entry verified: a browser fullscreen change event was received and the target element became the reported fullscreen element. This is the strongest confirmation available to this page.
Fullscreen exit verified: a fullscreen change event was received and the document stopped reporting an active fullscreen element.
API EXPOSED / LEGACY API: a request method exists. It is a capability check only; permissions, document state or the browser may still reject the request.
BLOCKED / NOT ENABLED: an exposed browser policy or document flag indicates fullscreen is unavailable in the current context. Try the direct tool page rather than a restricted iframe.
Fullscreen request failed: the browser rejected the operation, possibly because of a missing gesture, policy, unsupported platform, or inactive document. The error name is displayed without inventing a result.
State detected but no event verified: the document may appear fullscreen, but no qualifying transition event was observed for the request. The tool warns rather than counting a verified transition.
NOT EXPOSED / UNKNOWN: the browser does not provide the test method or its optional policy hints. This does not diagnose a broken screen or graphics card.

Browser Limitations

Fullscreen is a browser-mediated feature requiring transient user activation. Browser extensions, the current document state, display restrictions, iframe configuration or an explicit Permissions-Policy: fullscreen restriction may prevent it. Some iPhone browsers do not expose general element fullscreen at all, even if fullscreen video playback is possible; device and browser differences should not be interpreted as hardware failure. An embedded cross-origin frame may need the appropriate allow="fullscreen" permission from its host.

Pressing F11 or maximizing a desktop browser window may look similar, but they are browser-window actions rather than proof that this page's Fullscreen API request worked. Some browsers allow exiting with Esc or device-specific gestures without using the tool's exit button. API and policy information can be absent or privacy-restricted, so the tool treats missing optional details as unknown rather than denied. A fullscreen transition does not measure monitor resolution, refresh rate, color quality or GPU speed.

Common Mistakes to Avoid

Expecting automatic fullscreen: browser security deliberately requires a user action. Use one of the enter buttons.
Confusing method support with success: check the verified state-change counter, not only the API label.
Testing inside a blocked iframe: an embedded preview can deny the request even when the same browser supports fullscreen on the direct page.
Confusing F11 with page fullscreen: the visual appearance may be similar, but F11 alone does not set document.fullscreenElement for this test.
Assuming a missing error means success: if the request does not change browser state, the result remains unverified.
Thinking Reset will exit fullscreen: Reset clears this test's counters; use the exit button or Esc to leave fullscreen.

Frequently Asked Questions

Why did fullscreen fail when I clicked the button?

The browser may block the request because of a missing user gesture, iframe Permissions Policy, an inactive document or device/browser limitations. Check the displayed policy and error status, then try this tool in a direct browser tab. An unsupported iPhone element API is a browser compatibility issue, not proof of a damaged display.

Is this the same as pressing F11 in my browser?

No. F11 usually changes the browser window's own presentation. This tool calls the page Fullscreen API and verifies the browser-reported fullscreen element and change event. F11 alone is not counted as a successful API transition.

Why do browsers require a click instead of allowing automatic fullscreen?

Requiring deliberate user activation helps prevent deceptive pages from hiding normal browser UI without your consent. It also lets browsers block fullscreen in restricted contexts.

Is any data collected during this test?

No test-related network request or server upload is made by the widget. Fullscreen state, event counts and context hints are processed locally. A report is only copied or downloaded when you explicitly choose it, and the report does not contain browsing history or screenshots.

Does this work the same way on mobile browsers?

Not always. Android browsers, iPad browsers and desktop browsers may support element fullscreen, while some iPhone browser versions do not. On an unsupported device, the tool reports the unavailable API instead of simulating a fullscreen PASS. Actual video fullscreen support is a separate feature.

Conclusion

A verified browser fullscreen entry and exit confirms that the Fullscreen API and its change events worked in the current browser context. If the API is unavailable or blocked, test in a compatible top-level browser before assuming anything is wrong with your device. For a broader feature overview, see Browser Feature Detection.