Present a Keynote Treatment on Zoom Without Sharing Notes

By pitch.dogFoundation12 min read20 September 2026

Advertising

Present a Keynote Treatment on a Video Call Without Sharing Your Notes

Three separate objects are in play when you present a treatment over a call, and they only look like one thing because they're stacked on the same screen. There's the slideshow your client is supposed to see. There's the presenter display carrying your notes, your next-slide preview, and the timer. And there's the surface the call is actually broadcasting, which is chosen somewhere else entirely, in the conferencing app, at the moment you start sharing.

Keynote governs the first two. Zoom governs the third. Your display arrangement and your operating system quietly influence all three. From your chair, all three can look correct at the same time. The slideshow is advancing. Your notes are sitting safely on the left-hand display. Nothing seems wrong. Meanwhile the client is reading a rehearsal of your argument in the corner of a picture you thought was slideshow-only, because "my notes are over there" is only true when the shared surface is a single window and not the display it happens to sit on.

So there isn't a setting that solves this. There's a rehearsal: a harmless deck, a chosen share target, a deliberate audio state, and a second device that tells you what the far end actually received. Your own screen is not evidence. The receiver's screen is.

Build the rehearsal before you build the meeting

Make a deck you would not mind being photographed, screenshotted, and forwarded, then design it so failures announce themselves.

Three slides are enough. The first carries an unmistakable title in large type, something like REHEARSAL DECK — NOT CLIENT WORK, plus a solid block of color. The second is an ordinary content slide in a different color, with its slide number visible in a corner, and a presenter note that reads, in the notes field, IF THIS TEXT IS ON THE CLIENT'S SCREEN THE SETUP FAILED. The third holds a short audio clip you made yourself: a few seconds of you saying the date, or a tone you generated, or a single note struck on something in the room. Something you own, so the test doesn't depend on a track you'd have to clear later.

The loudness of those markers is the point. Video is compressed, window thumbnails are small, and a subtle watermark will leave you squinting and guessing whether a smudge is a marker or a compression artifact. You want the failure to be undeniable, so that the fix is obvious and the doubt isn't.

Keep everything real out of this deck. No client reference images, no fee pages, no treatment copy in progress, no screenshots of other people's work, no messages. The entire value of the rehearsal is that it can break. Nothing should break with it.

Before you start, write down the conditions: the macOS version, the Keynote version, the conferencing client's version and whether you're in the desktop app or a browser tab, the display arrangement, which meeting you're in, and who is permitted to share. This takes ninety seconds and it is the difference between diagnosing a problem and restarting everything in superstition. If something behaves unexpectedly, you want to know which of those variables changed since the last time it worked.

Keep the slideshow and the presenter display in separate places

Keynote's slideshow options include playing the presentation in its own window rather than letting it take over the display. Choose that. A window is a thing the call can be pointed at specifically; a full-screen slideshow is just your display wearing a costume, and pointing a call at a display means pointing it at everything on it.

The presenter display is separate again, and it gets its own window with your notes in it. In Keynote's slideshow settings you'll find an option controlling whether the presenter display window is made available to other applications. Turn it off for this. Then treat it as a control you have inspected rather than a promise you have secured, because Apple's own guidance on presenting remotely warns that some conferencing apps can still show the presenter display inside a shared screen area. The checkbox closes one common route. It does not close your obligation to check what's on the shared surface.

Two consequences follow from that, and both are easy to miss.

The first is that changing the setting changes the setup. If you flip that option one way for a rehearsal and back the other way before the client call, you have altered a condition and invalidated part of your test. Either settle it and leave it, or re-verify after changing it.

The second is that a window share is tied to the window you named, not to the role it plays. Close that window, end the slideshow and start it again, or launch it full-screen when you had it running in a window: any of these can replace the target you selected with something else, or with nothing at all. After any of them, choose the share target again, even if it feels redundant. Rearranging your displays is a different matter. It doesn't move a window share off its window, but it does change what a display share would broadcast, which is one more reason to keep the share pointed at a window.

If you have a second display, decide in advance which screen holds the slideshow and which holds the notes, and make that arrangement part of your written conditions. If you're mirroring, you don't have two displays, you have one surface wearing two frames, and the separation strategy has to change accordingly. The menu wording shifts between macOS and Keynote releases, incidentally, so read what your version actually says instead of matching a phrase you remember.

Point the call at one window, and identify it by sight

Zoom's sharing picker distinguishes a screen from a window, and which window you choose is your decision. Launching the slideshow does not choose it for you. So choose the slideshow window itself: not the entire desktop, not the presenter display, not a browser tab you were looking at earlier.

The trap here is naming. Share pickers tend to list windows under their application's name, and both your slideshow and your presenter display belong to Keynote. Two entries that both say Keynote are not equally suitable, and neither is the one labeled with your whole desktop. Insist on identifying the target by its content. Your rehearsal slide one has specific words and a specific color on it. Look at the thumbnail; if it isn't the thing you expect the client to be looking at, don't pick it. This is why the test deck is loud — it makes the right window recognizable at thumbnail size, which is the only size you get.

If the window you want isn't in the list, stop. That's the whole instruction. Close the picker, work out what's missing, and start again. Common causes are that the slideshow isn't in the state you think it's in, that the display arrangement has changed underneath you, or that your operating system hasn't granted the conferencing app permission to capture the screen at all. That last one is worth checking in advance, because on macOS the permission lives in system settings, and granting it may require quitting and reopening the app before sharing works at all. If you've just changed it, treat the entire sharing route as unverified again and re-run the rehearsal.

Do not reason your way past a missing window in front of a client. A window picker that doesn't show your slideshow is telling you something, and the moment to hear it is now.

One more note on sources, since the two systems disagree. Zoom's Keynote-specific guidance describes windowed versus full-screen presentation, but some of the preference wording in it predates Apple's current separation controls. When the two pages describe the Keynote side differently, follow Apple's current guidance for Keynote's own windows and verify the Zoom side yourself with the rehearsal rather than transcribing an older menu path from memory.

Decide what sound leaves the computer

Picture and sound are separate decisions. Zoom's sharing documentation treats audio as its own choice alongside the screen or window you picked, and selecting it transmits computer audio generally. It is not automatically narrowed to the window you chose for the picture. So when a treatment includes a tone reference or a temp track, enabling sound is a commitment to whatever your machine decides to play next.

Three things need checking, and they're distinct checks.

The clip arrives. Without the sound option enabled, the client watches a slide show in silence while you hear the reference track playing in the room. This is the most common way a treatment's music never reaches anyone, and it is completely invisible from your side of the call: your speakers are working, the clip is playing, everything sounds fine to the only person who isn't the audience.

Nothing else arrives. System alerts, message sounds, another app with audio in the background, a tab you left open. Deciding to share sound is deciding to share your computer's audio output, not just the file you had in mind. Quiet the machine before the call, or accept that anything that beeps is part of your presentation.

Your microphone and your computer's playback are different routes. If you want to test the clip cleanly, mute your microphone, play the clip, and let the second device report what it heard. Then unmute and speak, so the voice route gets its own verdict. Leaving the microphone open during the clip test blends two signals and leaves you unable to tell which one failed if something does.

Watch the whole sequence from the far end

Join the meeting from a second device as an ordinary participant: a phone, a tablet, a second laptop. Mute it, leave its camera off, and keep it in front of you. You aren't presenting to this device; you're observing from it.

Then walk the whole sequence, in order, checking the far end at each step.

Start the slideshow. The receiving device should show the slideshow window, not your desktop, not the presenter display, and not a frozen frame of whatever was on screen a second ago.
Advance one slide. Confirm the receiver's picture changes with yours. A transition is a moment when the shared surface can be rebuilt into something you didn't intend, so watch it rather than assuming the next slide behaves like the first.
Read the notes marker. The presenter note sits on this second slide, so this is the first point at which it can be checked. Look for it. If any part of it is legible on the receiving device, the setup is wrong. Stop and fix it; don't proceed to the real deck hoping it was a fluke.
Advance to the audio slide and play the clip. Step forward to the third slide before you test the sound, since that's where the clip lives. Confirm the receiver hears it, and confirm nothing else came through with it.
Return to the slides. Confirm you land where you expect.
End the slideshow. This is the step almost everyone skips, and it deserves the most attention. When the slideshow stops, its window closes, and what the call does about a disappearing shared window is worth seeing in advance rather than discovering live. Whether the share ends cleanly, holds a frozen image, or falls back to something else depends on the setup in front of you, and you should watch it happen on the receiving device instead of trusting a guess about it.

Then practise the last action: stop sharing deliberately, as its own step, before you touch anything else. Don't rearrange windows, don't open a message client, don't go looking for the next file while the share is still live. The end of a pitch is exactly when people relax and start dragging things around, which is how a client gets a look at their desktop.

What you carry into the real pitch

Finish the rehearsal with a short record: the versions you used, the window you shared, the audio state, the display arrangement, and every failure you found and fixed. This is not documentation for its own sake. Pitch day is not the moment to reconstruct what you did, and the record is what lets you reproduce it deliberately rather than hopefully.

On the day, the sequence becomes three things you can name out loud if you have to: this window, this audio state, this stop-sharing action. Then open the real deck.

The condition for moving to it is the whole reason the rehearsal exists. Not that your screen looks right, not that the share picker thumbnail looked plausible, not that the slides advanced on your display while you watched. Only that the receiving device showed you the slideshow you intended and heard what you intended, all the way through to the end of the show.

The reason to run all of this on a deck that literally says REHEARSAL is that a failed test should cost you twenty minutes and nothing else. The reason to run it at all is that your screen is a description of your intentions, and the only configuration you can rely on is the one you have watched from the other end of the call.

Frequently asked questions

Why isn't there a single Keynote or Zoom setting that keeps presenter notes private?

Three objects are in play: the slideshow the client sees, the presenter display with your notes, and the surface the call is broadcasting. Keynote governs the first two, while the conferencing app governs the third. Sharing a display can broadcast everything on it, and some conferencing apps can still show the presenter display inside a shared screen area.

What should a rehearsal deck contain, and why make it loud?

Three slides are enough: an unmistakable title such as REHEARSAL DECK - NOT CLIENT WORK, an ordinary content slide with a visible slide number and a presenter note saying IF THIS TEXT IS ON THE CLIENT'S SCREEN THE SETUP FAILED, and a short audio clip you own. Loud markers make a failure undeniable despite video compression and small thumbnails. Keep all real client material out.

A window is something the call can be pointed at specifically. A full-screen slideshow is just your display wearing a costume, and pointing a call at a display means pointing it at everything on that display. Closing, restarting, or changing the slideshow can replace the target, so reselect the share target after any of those actions.

Enabling sound transmits computer audio generally, not automatically just the window you chose for picture. Check that the clip arrives, that nothing else arrives, and that your microphone and computer playback are treated as separate routes. Test the clip with the microphone muted, then unmute and speak so the voice route gets its own verdict.

How do you verify the setup from the far end?

Join from a second device as an ordinary participant, muted with camera off. Start the slideshow, advance one slide, read the notes marker, advance to the audio slide and play the clip, return to the slides, then end the slideshow and watch what the call does when the shared window closes. Stop sharing deliberately before touching anything else. Only the receiving device shows what the client actually got.