Share Entire Screen and the viewer gets everything drawn on that display: notification toasts with the sender's name, the taskbar, the Alt-Tab switcher, any window you drag over. Share a Window and they get that one app's pixels and nothing else, so you can Alt-Tab, take a Slack toast, or bury it under three other apps and their stream never changes. Portion of Screen streams a fixed rectangle of your desktop, whatever sits inside it. Eight behaviours, side by side, below.
Eight behaviours, three share modes
Every cell describes what the viewer's stream renders, not what your own desktop shows. Those two diverge more than people expect.
| What happens on your machine | Entire Screen | Window | Portion of Screen |
|---|---|---|---|
| A notification toast (Slack, Outlook, Teams) | Rendered in full, sender name and preview included, unless you silenced them first. | Not rendered. The toast is a separate window, so it never enters the stream. | Only if the toast lands inside the rectangle. Windows draws toasts bottom right, so a bottom-right region is the risky one. |
| The taskbar and system tray | Rendered, including unread badges, pinned app names and hover previews. | Not rendered at all. | Only if the rectangle overlaps that strip of the display. |
| Alt-Tab or Task View | Rendered: the switcher plus a thumbnail of every open window, a bigger disclosure than the app itself. | Not rendered. The shared window keeps streaming live while you work elsewhere. Minimise it and the stream usually freezes on the last frame. | Rendered if the switcher overlaps the rectangle. Windows draws it near the centre, so a centred region shows it. |
| A window dragged on top of the shared one | Rendered in full. Occlusion is the point of a display capture. | Not rendered on a current Windows client: the shared window's own pixels keep streaming, the covering window is composited out. Older fallback paths invert this. | Rendered. Region capture sends whatever is drawn there, whichever app owns it. |
| A second monitor | Not rendered. You pick one display, the other stays private, but your pointer vanishes from the stream when it crosses over. | Not applicable. Capture follows the window, so dragging it to the other monitor never breaks the stream. | Not rendered. The frame lives on one display. Move it across if you like, it never spans both. |
| Resizing | Nothing changes for the viewer. The display is captured whole and scaled into their meeting window. Changing your screen resolution mid-share does change it. | The delivered frame changes shape live. Shrink the window and the viewer gets fewer pixels, so your code goes soft for them, not merely small for you. | Same effect. Dragging the capture frame's handles renegotiates the stream dimensions mid-share. |
| Zoom's own toolbar and green border | Not rendered. Zoom keeps its meeting interface out of its own capture, so no floating controls and no mirror-of-a-mirror. | Not rendered, it is a different window. | Not rendered. The green outline is drawn around the region, not inside it. |
| An overlay excluded from capture at OS level | Absent from the stream. | Absent from the stream. | Absent from the stream. |
One clean summary: Entire Screen captures a display, Window captures a window, Portion captures a rectangle. Almost every unpleasant surprise comes from assuming the middle one behaves like the other two.
Why sharing a single window leaks far less than people assume
The modern Windows capture path hands an app a window's own composited output, not a cropped photograph of the screen. The compositor draws each window into its own surface, so notifications, the taskbar and the app on top never reach the buffer Zoom reads. Hence row four: your screen shows the window buried, the viewer's stream shows it clean.
Three caveats worth knowing.
- Minimising is not the same as covering. A covered window keeps producing frames. A minimised one generally stops, leaving the viewer on a frozen frame that looks exactly like your machine has hung.
- Child windows can go missing. Drop-down menus, combo boxes and autocomplete popups are often separate top-level windows spilling outside the shared window's bounds. You see the menu open, the viewer sees nothing, then a value changes out of nowhere. It is the usual source of "wait, what did you just click?" in a shared IDE.
- A browser window is not a browser tab. Zoom lists each Chrome or Edge window separately, never each tab. Sharing a browser window shares every tab in it, and switching tabs is fully visible. A tab you want private must live in a different window.
In a shared-editor round that is the difference between a clean share and an accidental tour of your inbox, and it keeps the stream steady while you work the problem elsewhere with Code Copilot.
A 60 second test that settles it on your machine
Behaviour varies with client version, driver and capture path. Do not trust an article, this one included, over your own eyes.
Start a meeting with nobody in it
New Meeting in the Zoom desktop app. A solo meeting streams exactly like a real one.
Add an honest second pair of eyes
Join from your phone, mic and camera off, or press Record and check the file after. The phone is better: it shows the stream as it happens.
Share exactly what you will share on the day
Same mode, same window, same monitor layout. Testing on Screen 1 then sharing Screen 2 is how people learn their second monitor is not where they thought.
Run the eight rows
Fire a toast by messaging yourself on Slack, press Alt-Tab, drag a window over the shared one, walk the pointer onto the other monitor, resize, open a drop-down menu.
Watch the phone, not your desktop
Your own monitor is the least reliable source of truth in the room.
Notifications are the row that actually catches people out
Every other row is recoverable with an apology. A toast reading "Recruiter at the other company: still free Thursday?" is not. Two settings, before the call rather than during it.
- Zoom's own switch. The desktop client's Share Screen settings include an option to silence system notifications while you share your desktop. Turn it on. Wording shifts between releases, so look for the notification line in that pane, not one exact label.
- Windows Do Not Disturb, set by hand. Windows has an automatic focus rule for duplicating your display, and it does not fire for Zoom sharing, because sharing is not duplication. Toggle Do Not Disturb yourself from the notification centre before you join.
Where a capture-excluded overlay fits, and what it cannot do
The last row works differently. Windows lets a window be marked so the compositor strips it from any capture before an application receives the frame. OfferPilot AI uses that, so its overlay is absent from all three Zoom modes, and from Teams, Meet, OBS and a plain PrintScreen, while staying visible on your own monitor. Not a blur, not a black box: the pixels are not in the frame that gets encoded and sent. It is on every plan, free tier included, so the 60 second routine tests it before you rely on it.
The boundary matters as much as the capability. Capture exclusion covers screen sharing, recording and screenshots. It does nothing about a webcam, a lockdown browser that owns the machine, a proctor in the room, eye tracking, or a phone propped up as a second camera. Eyes reading something off to the side are visible on video, and a four second pause before every answer reads as a pause whatever caused it.
Where this guide runs out
- It describes the Windows desktop client. A browser, macOS, a virtual machine or remote desktop routes capture through a different pipeline, and the Window column especially can differ there.
- Clients change. Occlusion behaviour for window sharing has flipped before as capture APIs moved on. Re-run the test after a major update.
- Some rounds make all of this irrelevant. In a proctored assessment inside a lockdown browser, the environment controls the machine and share-mode nuance is beside the point. OfferPilot AI is the wrong tool there, and we would rather say so than sell you something that does not apply. It is Windows 10 and 11 only, built for live calls and preparation, not exams.
For an ordinary Zoom interview the takeaway is small. Share a window rather than a screen whenever the interviewer does not actually need your whole desktop, silence notifications anyway, and spend one minute proving it on your phone.
Related guides
- Does Screen Sharing Show My Second Monitor? What Each App Sends
- Microsoft Teams Share Window vs Share Screen: What Others See
- Webex Share Application vs Share Screen (and Share a Portion)
- Google Meet: Share a Tab, a Window, or Your Entire Screen?
- Whereby Screen Share: What Others Can See in Each Picker Tab