MacBook notch and menu bar dimensions by model

Last checked September 2026. One page for every Mac with a notch: the native resolution from Apple's own tech specs, the size of the notch and the menu bar in points and pixels, and what the macOS safe area APIs report. Measured where we could measure, sourced where we could not, and marked unverified where neither was possible. Updated at each Apple hardware or macOS release.

Last updated: September 2026

Published by the makers of Crest, an app that lives in the notch. Every resolution below was read from Apple's tech specs pages on 15 September 2026. Every figure marked measured comes from the AppKit code on this page, run the same day on a MacBook Pro (16-inch, 2024) with M4 Pro, model identifier Mac16,7, on macOS 26.6.2 (25G83). Apple does not publish the size of the notch. If you run the code on another model, write to contact@crestnotch.app with the output, your model identifier and your macOS build, and we add the row.

Every Mac with a notch

Twenty-one models across four panels, from Apple's model lists (both pages dated 14 September 2026) and each model's tech specs page. The notch arrived with the 14-inch and 16-inch MacBook Pro in October 2021 and the MacBook Air in 2022; every MacBook Pro and MacBook Air since has one. None of the 21 tech specs pages lists scaled resolutions or the default one, so those come from measurement, below.

Apple read from Apple's page · measured from the code on this page, on the Mac named above · derived arithmetic on a measured figure, not measured in that mode · unverified nobody has measured it yet

Every figure in this table is Apple. The screen sizes are Apple's diagonals; each specs page adds that the display has rounded corners at the top and a smaller viewable area than the rectangle implies.

The four panels, and what the notch measures

The notch is a hole in the panel, so its size is fixed in panel pixels and only its size in points changes with the resolution you pick. The chip never matters; the panel does. Four panels cover all 21 models.

One row is filled because one notched Mac was on the desk. We did not switch its display mode to take the default-mode reading, since that reflows every window on a machine somebody is working on, so the default-mode notch is arithmetic on the measured panel pixels and is marked as such. The other three panels stay unverified rather than assume they follow the 16-inch: the two MacBook Pro panels share a density and a bezel design, but a shared design is not a measurement. Run the code below on one of them and send the output.

What one Mac measured

The complete readout, so the figures above can be checked and the method repeated. Points are what AppKit reports; framebuffer pixels are points times the backing scale; panel pixels are the framebuffer scaled to the panel's native size.

The display mode list is a measurement too. At 2x the 16-inch offers 960 by 600, 1168, 1280 by 800, 1312, 1496, 1728 (default) and 2056 points wide, and every width except 960 and 1280 appears twice: once at full height and once 74 panel pixels shorter (1728 by 1117 and 1728 by 1080; 2056 by 1329 and 2056 by 1285; 1496 by 967 and 935; 1312 by 848 and 820; 1168 by 755 and 730). The shorter modes leave out a strip at the top of the panel, 74 pixels or 37 points at the default scale, taller than the 64 pixel housing itself. Apple's compatibility mode, the Get Info checkbox described below, runs an app below the camera by changing the active area of the display; we did not switch into those modes, so we list them as sizes and leave the mapping to Apple's description.

How scaling changes the numbers

Three different pixel counts describe one notch, and mixing them is how most published figures go wrong.

• Panel pixels never change: the housing covers the same physical pixels in every mode. On the measured 16-inch that is about 370 by 64.
• Points are what every AppKit API reports, and they change with the resolution setting: 220 by 38 at 2056 points wide, about 185 by 32 at the default 1728. The rule is panel pixels divided by panel pixels per point, and panel pixels per point is the native width divided by the current width in points.
• Framebuffer pixels are points times backingScaleFactor, which is 2.0 in every Retina mode on the measured Mac even when the framebuffer is larger than the panel, as it is at 2056 by 1329 (4112 by 2658 rendered down to 3456 by 2234).

So a figure without its mode is not a figure. Every number on this page names the mode it was taken in, and a reader quoting it should carry the mode along.

Reading the notch in AppKit

macOS 12 Monterey added three properties to NSScreen for the housing, all still current in macOS 26: safeAreaInsets, whose top inset is the notch's height in points and is zero on a screen without one; auxiliaryTopLeftArea and auxiliaryTopRightArea, the two rectangles beside the housing in global screen coordinates, nil in Swift on a screen without one. The notch's width is the screen width minus those two. Apple's own words for the first: "The safe area reflects the unobscured portion of the screen. On some Macs, the insets reflect the portion of the screen covered by the camera housing." This is exactly what Crest does at launch (NotchGeometry.probe in its source), so the code below is the app's method, not a demonstration written for the page.

import AppKit

for screen in NSScreen.screens {
    let inset = screen.safeAreaInsets.top             // 0 on a screen without a notch
    guard inset > 0,
          let left = screen.auxiliaryTopLeftArea,    // nil without a notch
          let right = screen.auxiliaryTopRightArea else { continue }
    let notchWidth = screen.frame.width - left.width - right.width
    let scale = screen.backingScaleFactor             // 2.0 in every Retina mode
    print("notch \(notchWidth) by \(inset) pt = \(notchWidth * scale) by \(inset * scale) framebuffer px")
    print("menu bar \(screen.frame.maxY - screen.visibleFrame.maxY) pt")   // visibleFrame stops under the menu bar
}
// Once the app has a main menu: NSApp.mainMenu?.menuBarHeight (39 on the measured Mac).
// NSStatusBar.system.thickness still answers 22 there; do not size anything with it.

Two more facts from the same run. NSScreen.visibleFrame is documented to exclude the menu bar and, in Apple's words, on Macs with a camera housing "does not include the bezel or the visible areas on either side of the bezel", so window placement that respects visibleFrame already clears the notch. And NSStatusBar.system.thickness is documented as 22, "which corresponds to the thickness of the menu bar"; that sentence predates the notch, the property still answers 22 on the measured Mac while the real menu bar is 39 points, so size nothing with it.

To find the default resolution rather than the current one, ask Core Graphics for the display's modes and look for the IOKit default flag. This is how the 1728 by 1117 figure above was taken:

import CoreGraphics

let id = CGMainDisplayID()
let opts = [kCGDisplayShowDuplicateLowResolutionModes: true] as CFDictionary
for mode in CGDisplayCopyAllDisplayModes(id, opts) as! [CGDisplayMode] where mode.isUsableForDesktopGUI() {
    let isDefault = mode.ioFlags & 0x4 != 0   // kDisplayModeDefaultFlag, IOGraphicsTypes.h
    print("\(mode.width) by \(mode.height) pt on \(mode.pixelWidth) by \(mode.pixelHeight) px", isDefault ? "default" : "")
}

Full-screen apps get all of this for free: with the system's full-screen experience, macOS positions the window's contents within the safe area, and the Human Interface Guidelines say the same for going full screen. An app that draws its own full-screen experience or paints over the menu bar audits itself, then sets NSPrefersDisplaySafeAreaCompatibilityMode to false in its Info.plist so the Finder stops offering the "Scale to fit below built-in camera" checkbox for it. Set it to true and macOS shrinks the active area of the display below the camera whenever the app puts a window behind it, for every app sharing that space, until the app quits.

What it means for menu bar apps

Apple's Human Interface Guidelines put the menu bar at 24 points. With a notch the bar grows to wrap the housing: 39 points on the measured Mac in its 2056-wide mode, about 10.7 percent of that bar's width under the notch (220 of 2056 points) and 918 points on either side. Nothing is drawn under the housing. App menus fill from the left; menu bar extras stack in from the right; each side stops at the housing.

That is why icons vanish. The guidelines say the system "hides and shows menu bar extras regularly", hides them "to make room for app menus", and when there are too many "may hide some to avoid crowding app menus". On a notched Mac the room runs out at the housing, not at the far edge of the screen, so the right-hand run of extras ends there and whatever does not fit is simply not shown, with no overflow menu. Apple's support article on the subject opens with the case directly: if "menu bar items appear blocked or hidden behind the camera housing", the offered remedy is the per-app "Scale to fit below built-in camera" setting, which drops the whole desktop below the camera while that app runs. A third-party utility that puts a menu bar item on a notched Mac should assume it can be hidden and never make the item the only way to reach something.

For an app that lives in the notch, as Crest does, the arithmetic runs the other way: 220 by 38 points on the measured Mac is the housing to draw around, and the two auxiliary areas are the wings a closed panel may extend into. On a display without a notch Crest draws a 196 by 32 point pill instead (NotchGeometry.swift), and its peek strip is designed around a 220 by 38 housing (DesignSystem.swift): the same figure this page measured, arrived at on the same model.

Sources

Every source with the date it was read, and the date on the page where Apple shows one. The 21 tech specs pages are linked from the first table; all were read on 15 September 2026.

• Apple, Identify your MacBook Pro model, support.apple.com/en-us/108052. Page dated 14 September 2026; read 15 September 2026. Names, model identifiers and years for every MacBook Pro row.
• Apple, Identify your MacBook Air model, support.apple.com/en-us/102869. Page dated 14 September 2026; read 15 September 2026. Names, model identifiers and years for every MacBook Air row.
• Apple Developer Documentation, NSScreen.safeAreaInsets, auxiliaryTopLeftArea, auxiliaryTopRightArea (each macOS 12.0 or later), visibleFrame, NSMenu.menuBarHeight, NSStatusBar.thickness and NSPrefersDisplaySafeAreaCompatibilityMode (macOS 12.0 or later). Read 15 September 2026.
• Apple Human Interface Guidelines, Layout (macOS: "Avoid displaying content behind the camera housing at the top edge of the window"), The menu bar ("The menu bar's height is 24 pt") and Going full screen. Read 15 September 2026.
• Apple Support, How to adjust an app's settings to appear below the camera area on your MacBook Air or MacBook Pro, support.apple.com/en-us/102125. Published 12 October 2023; read 15 September 2026.
• Apple Developer News, Unlock the power of the new MacBook Pro, 18 October 2021: the display "expands the active area of the display up around the new 1080p FaceTime HD camera". The only Apple page that announces the safe area properties; the AppKit release notes for macOS 12 and the WWDC21 AppKit session do not mention them. Checked 15 September 2026.
• Crest source, read at commit b2f5c1b on 15 September 2026: NotchGeometry.swift (the probe that reads the three NSScreen properties; the 196 by 32 pill on displays without a notch) and DesignSystem.swift (the 220 by 38 housing the peek strip is designed around).
• The measurement: the AppKit and Core Graphics code on this page, run with the Swift toolchain on a MacBook Pro (16-inch, 2024), M4 Pro, Mac16,7, macOS 26.6.2 (25G83), on 15 September 2026, in the 2056 by 1329 mode. Nothing on this page was taken from another site or from memory.

FAQ

Keep reading: Dynamic Island for Mac · Best Mac notch apps in 2026 · Claude Code in the notch · Facts and prices · Crest overview