Screen, Window, and Page Size in JavaScript: 5 Fatal Errors and How to Avoid Them

Size Matters: Why Scripts "Break" Layouts

Imagine: you write a perfect responsive website, test it on your laptop — everything works perfectly. You launch it on a client's tablet — a bug. Elements overlap, a modal window goes off-screen, and some gallery refuses to open at all. Sound familiar?

Most often, the root of the evil is incorrectly getting the dimensions of the screen, browser window, or the page itself. The question "Get the size of the screen, current web page and browser window" on Stack Overflow has garnered hundreds of thousands of views. And this is no coincidence: even experienced developers confuse screen.width, window.innerWidth, and document.documentElement.clientWidth.

In this article, we will break down the 5 most common errors that beginners (and not only) make when working with sizes in JavaScript. You will get not only the theory but also ready-made, proven solutions for real-world tasks.

Top 5 Errors When Working with Sizes in JavaScript

Error #1: Using screen.width Instead of window.innerWidth

This is a classic. A developer wants to know the width of the viewport and writes:

// ❌ Incorrect\nconst viewportWidth = screen.width;\nconsole.log(viewportWidth); // 1920 (but this is not the viewport!)\n

What's the catch? screen.width returns the physical width of the monitor in pixels. It does not change if you minimize the browser window or open developer tools. Meanwhile, window.innerWidth is the width of the viewport, i.e., the part of the window where content is displayed.

When this breaks the site: If you calculate responsive blocks based on screen.width, the site will not rearrange when DevTools is opened or the window is resized. The user will see either empty space or overlapping elements.

// ✅ Correct\nconst viewportWidth = window.innerWidth;\nconsole.log(viewportWidth); // Current width of the visible area\n

Error #2: Forgetting About the Scrollbar

The second most popular pitfall. A developer gets the window height and tries to place an element exactly in the middle:

// ❌ Incorrect\nconst windowHeight = window.innerHeight;\nelement.style.top = windowHeight / 2 + 'px';\n

At first glance, everything is correct. But if the content is longer than the screen and there is a scrollbar, window.innerHeight includes its height. As a result, the element might "slide" beyond the bottom edge of the visible area.

Solution: Use document.documentElement.clientHeight — it returns the viewport height without the scrollbar.

// ✅ Correct for positioning within the visible area\nconst viewportHeight = document.documentElement.clientHeight;\nelement.style.top = viewportHeight / 2 + 'px';\n

\n

Remember the rule: window.innerWidth/innerHeight — includes the scrollbar. document.documentElement.clientWidth/clientHeight — excludes the scrollbar. Choose based on the task.

\n

Error #3: Confusing Window Size and Page Size

You want to know how far the user has scrolled and calculate the total page height:

// ❌ Incorrect\nconst pageHeight = window.innerHeight;\nconsole.log(pageHeight); // This is not the page height!\n

window.innerHeight is the height of the window, not the document. To get the full page height (including the scrolled part), you need to use document.documentElement.scrollHeight.

Real-world example: You are implementing an infinite scroll. If you use window.innerHeight to determine when to load new posts, the script will fire once and then no