Google Slides on the desktop when you present from a Mac

The search for Google Slides on the desktop is rarely about editing. It is almost always made shortly before speaking, by someone who has just discovered that the deck lives in a browser tab, that the notes appear in a window which insists on covering the slides, and that the room's projector is showing a tab strip full of other work.

Presenting from a browser is perfectly workable. It simply has a handful of specific behaviours that need to be known in advance, because the moment to learn them is not while forty people wait.

There is no Slides application for macOS, and that shapes the room

The App Store listing for Google Slides is a mobile listing: it requires iOS 17.0 or later on iPhone and iPadOS 17.0 or later on iPad, and Mac is not listed. Google Drive for desktop does not change this, since its documentation states that files in Google Docs, Sheets and Slides open in the web browser while other files open in their default desktop applications.

So presenting means presenting from a browser window. That has one real advantage worth stating, because it is easy to resent the situation instead: there is no version mismatch and no missing font substitution at the last minute, since the deck renders in the same engine that built it. Anyone who has watched a presentation file reflow on a borrowed laptop knows what that is worth.

The costs are all about windows. A browser is designed to put many things in one window, and presenting needs the opposite.

Two windows, and one of them lands on the wrong screen

Google documents the flow plainly. Clicking Slideshow at the top right makes the presentation full screen from the current slide. Clicking the down arrow next to Slideshow reveals Presenter view, and from there Speaker notes. On a Mac, Cmd+Enter starts presenting directly, the s key opens speaker notes during a presentation, and the a key opens audience tools. English captions can be toggled with Cmd+Shift+C.

Presenter view is a second window. That is the whole source of the difficulty. With one display, the notes window and the full screen slides are competing for the same space, and the usual result is that the notes sit on top of the slides and have to be dragged mostly off the edge. With two displays it works, but only if the Mac is set to extend rather than mirror, and only if the two windows end up on the correct screens.

Getting that right is a habit rather than a setting. Check in System Settings that the displays are extended and not mirrored. Decide which display is the primary one, because the full screen slides open on the display holding the window that started them. Then start the slideshow, move it to the projector, and open presenter view afterwards so it appears on the laptop.

Rehearse the window arrangement once with the actual projector, because the display layout is remembered per configuration and a meeting room is a configuration the Mac has never seen. A layout that works in the office does not carry to a room where the projector reports itself as a different resolution.

Audience tools and what the a key opens

Audience tools are the part of presenter view most presenters never use, and it is worth knowing what happens before pressing the key in front of a room. Starting a session puts a short URL at the top of the slides during the presentation, and anyone who opens that URL can submit a question, optionally anonymously, and vote on questions others have asked. The presenter then chooses a question in the panel and clicks Present to put it on the slides.

The detail that surprises people is the URL on the slides. It is visible to the room for as long as the session runs, which is the intended behaviour in a lecture and an unwanted invitation in a meeting of six people who could simply speak.

The reason to know the key exists is defensive. Pressing a during a presentation opens a panel, and a presenter who does not recognise it will spend several seconds trying to get rid of it. The same applies to s: it opens the notes window, and on a single display that window lands on top of the slides.

Presenting into a video call is a different problem

A remote presentation has no projector, and the browser tab strip becomes the hazard instead.

Sharing the entire screen from a Mac shows everything, including the browser window behind the slides and the titles of every other tab in it. Tab titles are informative by design, which means a client name, a candidate's name or the title of a salary sheet can be legible to the whole call for a second before the slides go full screen. Sharing a single tab or a single window avoids it completely, and is the option to reach for by default.

There is a second trap in the remote case. When the meeting and the deck are both tabs in the same browser window, switching between them moves the shared surface, so the audience watches the presenter hunting for a tab. Keeping the meeting and the deck in two separate windows, or in a browser where each app already has its own window, makes the share stable regardless of what the presenter clicks.

Captions are worth a deliberate decision here as well. Cmd+Shift+C turns on captions inside the Slides presentation, and the meeting platform usually has its own captions too. Running both produces two sets of text competing for the bottom of the screen.

The account check that belongs in the five minutes before

A Google URL carries an account index in it, as the /u/0/ or /u/1/ segment, and that index refers to the order accounts were added to the browser profile rather than to a person. A deck link forwarded by a colleague carries their index, not the recipient's.

At any other time this produces a mildly annoying request-access screen. Two minutes before a presentation it produces a crisis, because the fix involves either signing in as a different account or opening the link in another profile, and both take longer than the audience will wait.

The check is short. Open the deck from the link that will actually be used, confirm the account shown in the top right corner is the one with access, and start the slideshow once to confirm it goes full screen. Doing this the day before is better. Doing it at all is the point.

Where two Google accounts are routinely in play, the durable fix is to stop relying on which account the browser happens to be showing. One session per account, with the presentation window living inside the right one, removes the guess. That is what browser profiles do in Chrome and what separate workspaces do in a browser built around them.

Presenting with no network

Offline presenting is possible and the requirements are strict. Google's documentation for offline use of Docs, Sheets and Slides states that it works in the Google Chrome or Microsoft Edge browsers, that the Google Docs Offline extension must be installed and enabled, that setup requires an internet connection, that private or incognito browsing will not work, and that only one account per browser profile can have offline enabled.

Three things follow for a presenter. Safari cannot do it, so a Safari web app for a deck is an online-only window however app-like it feels. Offline has to be arranged while still connected, which means before leaving rather than after arriving. And the single-account-per-profile rule means that a deck belonging to a second Google account needs a second browser profile prepared in advance.

One further caution applies specifically to presentations. Embedded video is the part that most often fails without a network, since a clip hosted elsewhere is fetched at play time even when the deck itself is cached. A deck that depends on a video needs either a downloaded copy of the clip opened separately or a plan to talk over a still image.

Route	Slides on the projector	Notes in front of the presenter	Works with no network	Cost
Tab in the main browser window	Yes	Yes, with window juggling	Only if that profile has offline enabled	None
Safari, Add to Dock	Yes	Yes, as a second window	No	Under a minute
Chrome, Install page as app	Yes	Yes, as a second window	Yes, with the offline extension	Under a minute
Export to a slide file and present locally	Yes	Yes, in the local application	Yes	Fonts and layout may shift
A browser with one window per app	Yes	Yes	Depends on the engine	A download

The export row deserves one honest note. Downloading the deck as a slide file does give a genuinely local presentation with no dependency on anything, and it is the safest option for a room with unknown networking. The price is that the layout is re-interpreted by the receiving application, so it has to be checked slide by slide rather than trusted.

The interruptions that land on the projector

Everything on the Mac is visible once a display is extended to a room, and a browser signed into a dozen services is a generator of visible events.

Message toasts are the obvious one, and a Focus mode set before the meeting handles them. Less obvious are the ones a browser produces on its own: a download bar sliding in, an update prompt, a permissions request from a background tab, a video starting to autoplay in a tab that was reloaded. None of these are notifications in the system sense, so turning notifications off does not stop them.

The reliable answer is to present from a window that contains only the deck. A dedicated window has no tab strip to leak titles, no download bar belonging to other work, and nothing else in it that can request attention. That is available three ways: Safari's Add to Dock from macOS Sonoma 14 onward, Chrome's Install page as app option under More, then Cast, save and share, or a browser where per-app windows are the normal arrangement rather than something to set up per deck. The supported apps list shows which services come configured that way.

Rebuilding this on a borrowed Mac

Presenting from someone else's machine, or from the Mac wired into a meeting room, is common enough to plan for, and none of the setup above travels.

What travels is the deck link and the account. What does not travel is the offline cache, the installed web app, the browser profile and the display arrangement. On a borrowed Mac the realistic sequence is to open the browser that is already there, sign in, open the deck from the link, and present from a normal window while accepting that a tab strip is visible if the entire screen gets shared.

Two precautions make that tolerable. Use a private window so that the sign-in does not outlive the meeting, remembering that private browsing rules out offline access, and check before starting whether anything else is already open on that machine that will appear on the projector. A meeting room Mac usually has someone else's work on it.

What to change first

Before the next presentation, do two things while still connected and not in a hurry: open the deck from the exact link that will be used and confirm the account, then start the slideshow once with the real projector attached to see which display it claims. If presentations happen weekly rather than twice a year, move the deck out of the shared browser window entirely and give it a window of its own, which a browser such as SpaceDeck does for every app without a setup step per file.