Introduction

Detecting orientation changes matters when a layout, media experience, or input model should react differently in portrait and landscape modes. On the web, the modern approach is to use the Screen Orientation API or responsive CSS rather than the older orientationchange event.

Modern Web Detection with screen.orientation

The current browser-facing API is screen.orientation. You can read the current orientation type and listen for its change event.

1function updateLayout() {
2  const type = screen.orientation.type;
3
4  if (type.startsWith("landscape")) {
5    console.log("Landscape layout");
6  } else {
7    console.log("Portrait layout");
8  }
9}
10
11screen.orientation.addEventListener("change", updateLayout);
12updateLayout();

This gives you more structured information than older APIs because you can inspect both type and angle.

1screen.orientation.addEventListener("change", (event) => {
2  console.log(event.target.type);
3  console.log(event.target.angle);
4});

Use CSS When the Goal Is Only Layout

If you only need to restyle the interface, JavaScript is often unnecessary. CSS media queries are simpler and more robust for pure presentation changes.

1@media (orientation: portrait) {
2  .sidebar {
3    display: none;
4  }
5}
6
7@media (orientation: landscape) {
8  .sidebar {
9    display: block;
10  }
11}

This is usually the best choice for responsive design because it keeps layout concerns in CSS instead of mixing them into application logic.

A Useful Fallback with matchMedia

When you want JavaScript behavior tied to orientation but also want a lightweight interface, matchMedia works well:

1const portraitQuery = window.matchMedia("(orientation: portrait)");
2
3function handleOrientation(event) {
4  if (event.matches) {
5    console.log("Now in portrait mode");
6  } else {
7    console.log("Now in landscape mode");
8  }
9}
10
11portraitQuery.addEventListener("change", handleOrientation);
12handleOrientation(portraitQuery);

This is especially convenient when your logic already revolves around responsive breakpoints.

Avoid the Old orientationchange Event

You will still find examples using:

window.addEventListener("orientationchange", () => {
  console.log("changed");
});

That older event is deprecated and non-standard. Modern browser guidance points developers toward screen.orientation and its change event instead.

If you maintain older code, it may still work in some environments, but it is not the best foundation for new development.

Handling Real UI Updates

In practice, orientation changes usually require more than a console log. Typical actions include:

• recalculating canvas dimensions
• reflowing a gallery or chart
• re-running a measurement-based layout function
• changing media controls or navigation placement

A realistic handler often reads measurements after orientation changes:

1function resizeCanvas(canvas) {
2  canvas.width = window.innerWidth;
3  canvas.height = window.innerHeight;
4}
5
6const canvas = document.querySelector("canvas");
7
8screen.orientation.addEventListener("change", () => {
9  resizeCanvas(canvas);
10});
11
12resizeCanvas(canvas);

The important point is that orientation detection should lead to idempotent layout logic, not fragile one-off DOM mutations.

Mobile App Perspective

In native mobile development, orientation changes are usually handled through platform lifecycle or configuration APIs rather than a web event. The core idea is still the same: detect the state change, then rebuild or adjust the UI in a way that preserves user state.

Even if your project is not a browser app, the design lessons carry over:

• keep orientation handling separate from business logic
• preserve important user state
• prefer declarative layout systems when possible

Common Pitfalls

The first pitfall is using JavaScript for layout changes that CSS could handle more cleanly. If the only requirement is responsive styling, use media queries.

Another pitfall is relying on the deprecated orientationchange event for new code. It may still appear in tutorials, but it is not the recommended modern API.

A third pitfall is assuming orientation alone fully describes the UI context. Screen size, safe areas, keyboard presence, and viewport changes can matter just as much.

Finally, remember to test on real devices. Browser emulation is helpful, but orientation behavior often feels different on actual hardware.

Summary

• On the web, prefer screen.orientation and its change event
• Use CSS media queries when orientation only affects styling
• 'matchMedia("(orientation: portrait)") is a useful JavaScript-friendly fallback'
• Avoid building new code around the deprecated orientationchange event
• Treat orientation changes as part of responsive UI design, not as isolated device trivia