Overview
Read the display and window facts of your own browser: viewport and screen sizes, device pixel ratio, the Tailwind breakpoint you are currently in, color depth, language, timezone, CPU core count, and touch support. Values update live as you resize the window.
How It Works
Open the tool and the twelve information cards fill immediately. Resize the browser window and every size-dependent card updates live, including viewport, orientation, and the current Tailwind breakpoint. Use it on the device you are debugging, or send the page to a client or tester and ask them to read off the values when reporting a layout problem.
Step-by-Step Usage Guide
- Open the tool on the device or window size you want to inspect.
- Resize the window and watch the viewport, orientation, and breakpoint cards update.
- Note the device pixel ratio when images or borders look blurry or sharp.
- Read the full card set back to support or include it in a bug report.
Technical Specifications & Standards
The cards distinguish three different size concepts that are easy to conflate. Viewport is the CSS pixel size of the window content area, the number media queries and window.innerWidth report. Physical screen is screen.width and height, the display's own resolution in CSS pixels, which on a 2x display is half the raw panel pixels. Available screen subtracts operating system reserved areas like the taskbar, so it can be smaller than the physical screen. Device pixel ratio is the multiply factor between CSS and device pixels. The breakpoint card maps the viewport through the standard Tailwind cutoffs: 640, 768, 1024, and 1280 CSS pixels. Orientation is derived from viewport width versus height rather than the screen orientation API. Cores reports hardwareConcurrency, which browsers may cap or fuzz, and memory reports deviceMemory, a Chrome-only hint that rounds to a power-of-two value and caps at 8 GB, so treat both as approximate. Touch is detected by the presence of ontouchstart, and online reflects the browser's network state flag.
Targeted Use Cases
- Debugging which Tailwind breakpoint a layout problem occurs at.
- Checking device pixel ratio when screenshots look soft on a client's screen.
- Confirming whether a device reports touch support before wiring touch interactions.
- Collecting environment details for a bug report without asking users to open devtools.
Notes & Gotchas
- Compare viewport against physical screen to spot browser zoom, which changes viewport but not the screen values.
- Treat the core and memory cards as hints, not specifications; browsers cap and round them.
- Remember orientation here is width versus height, not the OS rotation lock state.
- Resize across breakpoints deliberately when testing responsive changes.
Frequently Asked Questions
Why is the viewport smaller than my screen?
The viewport measures the window's content area, which excludes browser chrome and anything the operating system reserves such as the taskbar. The Available screen card shows the screen minus those reserved areas.
Why does the memory card show a small set of values?
The device memory hint rounds down to a power of two and caps at 8 GB, and it is not available in every browser. It is a coarse capability signal, not an installed-RAM readout.
Which breakpoint am I in right now?
The Tailwind breakpoint card answers exactly that, using the 640, 768, 1024, and 1280 pixel cutoffs applied to the current viewport width, and it updates live as you resize.
Does the tool detect my screen's refresh rate or GPU?
No. It reports sizes, pixel ratio, color depth, and capability hints only. Rendering hardware is intentionally not probed here.