How to Check If a DOM Element Is Visible in the Viewport in JavaScript

By the end of this page, you will understand how to check whether a DOM element is visible in the current viewport, what “visible” can mean in practice, and which JavaScript approaches are commonly used. You will also learn when to use getBoundingClientRect() and when IntersectionObserver is a better fit.

In browser JavaScript, checking whether an element is visible in the viewport usually means asking:

• Is the element's position inside the currently visible browser window?
• Is any part of it on screen, or must the entire element fit inside the viewport?

This is different from other meanings of “visible,” such as:

• Whether CSS hides the element with display: none
• Whether it has visibility: hidden
• Whether it is covered by another element
• Whether it exists in the DOM at all

For viewport visibility, the most common low-level tool is element.getBoundingClientRect(). This returns the element's size and position relative to the viewport.

With that rectangle, you can compare:

• rect.top
• rect.bottom
• rect.left
• rect.right

against the viewport dimensions:

• window.innerWidth
• window.innerHeight

This matters in real programming because many features depend on whether something is on screen:

• Lazy-loading images
• Triggering animations when sections scroll into view
• Tracking what content a user has seen
• Avoiding expensive rendering work for off-screen elements

For one-time checks, getBoundingClientRect() is simple and direct. For repeated visibility tracking during scrolling, IntersectionObserver is usually the modern and more efficient choice.

Think of the viewport as a camera frame and the DOM element as a poster on a wall.

• The browser window is the camera view.
• The element has edges: top, bottom, left, and right.
• If the poster overlaps the camera frame at all, some part of it is visible.
• If the entire poster fits inside the frame, it is fully visible.

So the job is really just rectangle overlap.

• Element rectangle
• Viewport rectangle
• Check whether they overlap

If they overlap, the element is in view. If not, it is outside the current viewport.

The classic approach uses getBoundingClientRect().

Check if any part of the element is visible

function isElementInViewport(el) {
  const rect = el.getBoundingClientRect();

  return (
    rect.top < window.innerHeight &&
    rect.bottom > 0 &&
    rect.left < window.innerWidth &&
    rect.right > 0
  );
}

Example

const box = document.querySelector('.box');

if (isElementInViewport(box)) {
  console.log('The element is at least partially visible.');
} else {
  console.log('The element is outside the viewport.');
}

This works because:

• rect.top < window.innerHeight means the element's top edge is above the bottom of the viewport
• rect.bottom > 0 means the element's bottom edge is below the top of the viewport
• rect.left < window.innerWidth means the element's left edge is left of the viewport's right side
• rect.right > 0 means the element's right edge is right of the viewport's left side

Together, these checks confirm overlap.

Check if the whole element is visible

function isFullyInViewport(el) {
  const rect = el.getBoundingClientRect();

  return (
    rect.top >= 0 &&
    rect.left >= 0 &&
    rect.bottom <= window.innerHeight &&
    rect.right <= window.innerWidth
  );
}

This version requires every edge of the element to stay inside the viewport.

Modern approach: IntersectionObserver

const target = document.querySelector('.box');

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      console.log('Element is visible in the viewport.');
    } else {
      console.log('Element is not visible in the viewport.');
    }
  });
});

observer.observe(target);

Use this when you want the browser to notify you as visibility changes, instead of checking manually on every scroll.

Consider this code:

function isElementInViewport(el) {
  const rect = el.getBoundingClientRect();

  return (
    rect.top < window.innerHeight &&
    rect.bottom > 0 &&
    rect.left < window.innerWidth &&
    rect.right > 0
  );
}

Suppose the viewport size is:

window.innerWidth = 1200;
window.innerHeight = 800;

And getBoundingClientRect() returns:

{
  top: 700,
  bottom: 900,
  left: 100,
  right: 500
}

Step-by-step

1. rect.top < window.innerHeight

   • 700 < 800
   • true
   • The top of the element is above the bottom of the viewport.

2. rect.bottom > 0

   • 900 > 0
   • true
   • The bottom of the element is below the top of the viewport.

3. rect.left < window.innerWidth

   • 100 < 1200
   • true
   • The element starts before the right edge of the viewport.

4. rect.right > 0

   • 500 > 0
   • true
   • The element extends past the left edge of the viewport.

Because all four conditions are true, the element overlaps the viewport and is visible.

Example where it is not visible

If the rectangle were:

{
  top: 900,
  bottom: 1100,
  left: 100,
  right: 500
}

Then:

• rect.top < window.innerHeight
• 900 < 800
• false

That means the entire element is below the viewport, so it is not currently visible.

Viewport visibility checks are used in many real applications.

Lazy-loading content

• Load images only when they are about to appear
• Fetch more data when a section enters view
• Delay video initialization until needed

Scroll-based animations

• Fade in cards as the user scrolls
• Start number counters when statistics become visible
• Trigger section transitions only once they appear

Analytics and tracking

• Record when a user has actually seen a banner
• Measure which articles or sections were viewed
• Track ad impressions more accurately

Performance optimization

• Skip expensive updates for off-screen components
• Pause rendering for hidden content
• Limit DOM work to visible areas in large pages

Infinite scrolling

• Detect when a sentinel element reaches the viewport
• Automatically load the next page of results
• Improve long-list browsing without manual pagination

In real projects, developers usually do not scatter raw viewport checks everywhere. They wrap the logic in reusable functions, hooks, or observers.

Common patterns

Utility function for one-off checks

function isElementInViewport(el) {
  const rect = el.getBoundingClientRect();
  return rect.top < window.innerHeight && rect.bottom > 0;
}

This is common for simple vertical visibility checks.

Guard clauses

function highlightIfVisible(el) {
  if (!el) return;
  if (!isElementInViewport(el)) return;

  el.classList.add('highlight');
}

Guard clauses keep the code simple and avoid nested conditions.

Scroll event with throttling or debouncing

In older code or simple pages, developers may check visibility on scroll. Because scroll events fire often, they usually throttle the handler.

let ticking = false;

window.addEventListener('scroll', () => {
  if (ticking) return;

  ticking = true;

  requestAnimationFrame(() => {
    const el = document.querySelector('.box');
    if (el && isElementInViewport(el)) {
      console.log('Visible');
    }
    ticking = false;
  });
});

IntersectionObserver for repeated tracking

This is the preferred pattern in many modern codebases.

const observer = new IntersectionObserver((entries) => {
  for (const entry of entries) {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
    }
  }
}, { threshold: 0.25 });

This means the callback runs when at least 25% of the element is visible.

Validation before observing

const el = document.querySelector('.card');
if (el) {
  observer.observe(el);
}

Real code should always handle missing elements safely.

Beginners often mix up viewport visibility with CSS visibility.

Mistake 1: Assuming viewport visibility means CSS-visible

const rect = el.getBoundingClientRect();
console.log(rect.top >= 0);

This does not tell you whether the element is hidden by CSS. An element can have coordinates and still be hidden with styles.

To avoid this mistake, remember:

• getBoundingClientRect() checks position and size
• CSS properties like display: none and visibility: hidden are separate concerns

Mistake 2: Checking only one edge

Broken example:

function isVisible(el) {
  const rect = el.getBoundingClientRect();
  return rect.top >= 0;
}

This is incomplete. An element below the viewport can still have rect.top >= 0.

Use a full overlap check instead.

function isVisible(el) {
  const rect = el.getBoundingClientRect();
  return (
    rect.top < window.innerHeight &&
    rect.bottom > 0
  );
}

Mistake 3: Forgetting horizontal visibility

If horizontal scrolling or wide layouts matter, checking only top and bottom is not enough.

return rect.top < window.innerHeight && rect.bottom > 0;

This is fine for many pages, but not for all layouts. Add left/right checks when needed.

Mistake 4: Running expensive checks on every scroll event without control

Broken pattern:

window.addEventListener('scroll', () => {
  document.querySelectorAll('.item').forEach((el) => {
    console.log(el.getBoundingClientRect());
  });
});

This can hurt performance.

Better options:

• Use IntersectionObserver
• Throttle scroll handling
• Limit how many elements you check

Mistake 5: Not handling null

const el = document.querySelector('.missing');
console.log(el.getBoundingClientRect());

This throws an error if the element does not exist.

Safer version:

const el = document.querySelector('.missing');
if (el) {
  console.log(el.getBoundingClientRect());
}

Here is how the main approaches compare.

Partial vs full visibility

Viewport visibility vs CSS visibility

// Partially visible
function isElementInViewport(el) {
  const rect = el.getBoundingClientRect();
  return (
    rect.top < window.innerHeight &&
    rect.bottom > 0 &&
    rect.left < window.innerWidth &&
    rect.right > 0
  );
}

// Fully visible
function isFullyInViewport(el) {
  const rect = el.getBoundingClientRect();
  return (
    rect.top >= 0 &&
    rect.left >= 0 &&
    rect.bottom <= window.innerHeight &&
    rect.right <= window.innerWidth
  );
}

Rules to remember

• getBoundingClientRect() gives position relative to the viewport
• Use overlap logic for partial visibility
• Use inside-boundary logic for full visibility
• window.innerWidth and window.innerHeight give viewport size
• IntersectionObserver is usually better for continuous tracking

Common edge cases

• Element exists but is hidden by CSS
• Element has zero size
• Horizontal overflow matters
• Scroll handlers run too often
• The selected element may be null

How do I know if an element is visible on screen in JavaScript?

Use element.getBoundingClientRect() and compare its edges to the viewport size. If the rectangles overlap, the element is visible in the viewport.

What is the easiest way to check viewport visibility?

For simple checks, use getBoundingClientRect(). For ongoing tracking during scrolling, use IntersectionObserver.

Does getBoundingClientRect() tell me if an element is hidden with CSS?

No. It tells you the element's size and position relative to the viewport, not whether it is hidden by display: none or visibility: hidden.

How can I check whether the whole element is visible?

Make sure top >= 0, left >= 0, bottom <= window.innerHeight, and right <= window.innerWidth.

Is IntersectionObserver better than scroll events?

Usually, yes. It is more efficient and easier to manage when visibility needs to be tracked over time.

Can an element be partially visible and still count as visible?

Yes. In many applications, partial visibility is enough. It depends on your definition of “visible.”

Why should I include left and right checks?

They matter when horizontal scrolling or wide layouts are possible. Without them, you only know about vertical visibility.

• DOM selection — You need to find elements with methods like querySelector() before checking visibility.
• getBoundingClientRect() — This is the core browser API used to measure element position in the viewport.
• IntersectionObserver — A modern API for reacting to visibility changes efficiently.
• Scroll events — Older but still common way to trigger viewport checks while the user scrolls.
• Debouncing and throttling — Useful for reducing the cost of repeated visibility checks.
• CSS display and visibility — Related because viewport visibility is not the same as being shown by CSS.
• Lazy loading — A common feature built on top of viewport detection.
• Event handling — Important when wiring visibility logic to scrolling, resizing, or user interactions.