A window on macOS can decline to appear in a screen share. No trick of layering is involved and nothing is cropped after the fact. Every window on your Mac carries a sharing property, and when the app that owns a window sets that property to none, the part of the system that assembles your desktop leaves the window out of the picture it hands to anything capturing the screen. The window stays on your display, exactly where you put it. It is simply absent from the stream.
That is the answer in full. What follows is how the mechanism works, how it differs from the workarounds people reach for first, and where its edges are, because a privacy measure you do not understand is one you will misuse on the call that matters.
Your Mac draws two pictures
It helps to stop thinking of a screen capture as a photograph of your display.
On macOS a single system process composites every window into the image you see. Your apps do not draw to the screen directly. They draw their own windows, hand them over, and the compositor decides what sits in front of what, with which shadow, at what scale, on which display. What you are looking at is a picture assembled for you.
When something asks to capture the screen, that same compositor assembles a second picture. It is built from the same windows at the same moment, for a different audience: the screenshot key, a screen recording, or a conferencing app that has been granted Screen Recording permission in System Settings. Most of the time the two pictures are identical, which is exactly why it is easy to forget there are two of them at all.
The sharing property is how a window says which of the two it belongs in.
Because the decision happens during compositing, nothing downstream has to cooperate. The conferencing app is not asked to filter anything and could not decline, because the frames it receives never contained the window in the first place. There is no visible hole either. The windows behind the hidden one composite normally, so the far side sees an ordinary desktop rather than a desktop with something conspicuously removed.
The property every window carries
In AppKit the property is sharingType on NSWindow, and it takes one of three values.
| Value | What a capture sees | Where you meet it |
|---|---|---|
.readOnly |
The window, composited normally | The default. Every window starts here unless its app says otherwise |
.none |
Nothing. The window is skipped entirely | Notes, credentials, anything you would not mirror |
.readWrite |
The window, and historically also open to being driven by another process | Deprecated on current macOS. Not a value to reach for |
Two things about this are worth holding on to.
The first is that no permission is involved. An app asks you for nothing to set it, there is no entitlement to request, and no prompt appears. That sounds alarming until you notice which direction it runs in. The property only ever removes the app's own window from a capture. It cannot touch anyone else's window, it cannot read the capture, and it cannot stop a capture from happening. It is a window declining to be included, not an app reaching outward.
The second is that it belongs to a window and not to an app. A window created later starts at the default like any other. An app that wants a consistent policy has to apply it to everything it owns, including the things you do not picture as windows: panels, popovers, alerts, and the small confirmation that appears for a second and disappears.
If you build Mac apps
One line, on each window you own.
// The compositor stops including this window in any capture stream.
window.sharingType = .noneSet it where the window is made, so there is no frame in which the window exists at the default. If the policy is something a person can toggle in your settings, apply the new value to every window the app already has open rather than only to windows created afterwards. A toggle that quietly skips the windows that existed before you flipped it is worse than no toggle at all, because it teaches people to trust something that is only partly true.
How this differs from the usual workarounds
Cropping or region sharing
Several conferencing and streaming tools let you share a rectangle instead of a display. The crop is applied by that tool, to a stream that already contains everything on your screen. This holds until the geometry moves. A window you drag, a system alert placed wherever the system likes, a display you unplug, a resolution change: any of those can put something inside the rectangle that you meant to keep outside it. A crop also places the whole burden on the piece of software furthest from the system.
Sharing one window instead of a display
This is a real answer and often the right one. What it costs is movement. The share follows one window, so switching apps mid call either shows the far side nothing useful or forces you to change what you are sharing while people watch. What the other side sees walks through each sharing mode and what it leaks.
A second display
Solid, as long as the discipline holds. The private material lives on a display you never share and never mirror. The failure mode is arrangement rather than software: mirroring turned on for a demo, a different desk with a different setup, or a window that opens on the wrong screen because that is where you left it last week.
Closing everything first
Free, and more reliable than it gets credit for. It depends on two things. You have to remember every time, and nothing can arrive during the call. Notifications are the usual leak here, and they are worth handling on their own terms whatever else you do.
The sharing property differs from all four because it needs no choreography at the moment it matters. Nothing has to be closed, moved, cropped, or remembered while people are watching.
What it protects, and what it does not
Be precise about the boundary. The property governs what the system composites into a capture. It has nothing to say about anything outside that path.
- A camera pointed at your display sees everything. A phone held up, a photograph of a monitor, a person standing behind you in a shared office: none of that goes anywhere near the compositor.
- The window has to be a real window. Content drawn inside another app's window, a browser tab, or a panel hosted by something else belongs to a window that its own app does not own and cannot set this on.
- The menu bar is the honest exception. A status item lives in a window the framework owns, and that window will accept the property and carry on drawing into captures regardless. When you share a whole display the menu bar is in the shot anyway, so the useful question is what your menu bar items are showing rather than whether they are visible.
- It is Apple's mechanism rather than ours, so treat it as a strong privacy measure and not a guarantee, and check it against your own setup before a call that matters.
That last point is not a disclaimer for its own sake. Capture on macOS has more than one path through it, conferencing apps update on their own schedules, and the only setup whose behaviour you actually need to know is the one in front of you.
Checking it yourself, in about two minutes
The screenshot key is the fastest honest test, because a screenshot travels the same capture path a share does.
- Put the window somewhere obvious on the display you plan to share.
- Press ⇧⌘3 for a full screen capture, or ⇧⌘5 and choose to capture the entire screen.
- Open the file that lands on your desktop. If the window is not in it, the property is in force on that display.
- Repeat with a screen recording from the ⇧⌘5 toolbar. A still and a recording are both captures, and watching both come back clean is more convincing than assuming the second from the first.
Then run the test that actually counts. Start a meeting on the service you will use, join it from a phone or a second computer, and share exactly what you intend to share on the day, in the same mode: one window, or a whole display, or a browser tab. Look at the far side with your own eyes. Do that once per service, and again after any large update to it, and you will know rather than hope. If you use several services, they are worth checking separately, since each one decides for itself how it asks macOS for the screen.
Where HushNotes comes in
HushNotes is a menu bar notes app, and every note window it opens sets this property. It is on by default, needs no permission, and requests none. Flipping the toggle in Settings re-applies the policy to every window the app already owns rather than only to the next one it makes.
The menu bar icon is the disclosed exception described above. It holds a 20pt icon and no note content, and macOS keeps it visible. One consequence is worth knowing before it surprises you: the same property that keeps a note off a call keeps it out of your own screenshots, so turn the toggle off for a moment when you want to capture your own notes.
If invisibility on a call is not the whole problem, because the person you are thinking about is sitting at your desk rather than watching a stream, that is a different layer. Any note can be locked behind Touch ID, with its body encrypted at rest while its title stays searchable, so a locked note is still a note you can find.
Read next
- What the other side sees when you share your Mac screen, a pre-call audit covering notifications, the menu bar, Spaces and second displays.
- How to take notes during a call without anyone seeing, which weighs this approach against presenter view, a second monitor and paper.
- The feature page for screen-share privacy shows one desk captured twice, once as its owner sees it and once as a share sees it, and floating notes covers the windows themselves.
Was $14.99 now $9.99, pay once · macOS 14 or later
