Yes, Canvas can see when you switch tabs, but the mechanism is the browser reporting window visibility, not Canvas reading your screen. When you leave a tab, the browser fires a visibilitychange event and sets document.visibilityState to hidden. Canvas—like any web page—can listen for that signal. What Canvas cannot see is what you did in the other tab, what other applications you opened, or your screen.
How visibility detection works under the hood
Every modern browser implements the Page Visibility API. This is a standardized interface that tells a document whether it is currently visible to the user. When you minimize a window, switch tabs, or move to another desktop, the browser updates a visibility state and dispatches an event.
The API exposes two main pieces:
document.visibilityState, which returns "visible" or "hidden" (with "prerender" historically reserved for pages loaded in the background). The visibilitychange event, fired on the document each time that state changes.
A web application registers a listener on the document and reacts. The code is trivial: document.addEventListener('visibilitychange', ...). Canvas's web client is a JavaScript application, so it has access to the same API as any other page.
The deeper question is why the browser exposes this at all. Historically, browsers throttle background tabs to save CPU and battery—timer callbacks slow to once per second or less. The visibility API was formalized so that pages could cooperate: pause animations, stop polling, and resume cleanly on return. That design purpose explains why the signal exists. It also explains why the signal is coarse: the browser tells the page that this document is hidden, nothing more.
Crucially, the event fires on the document itself. The page receives a boolean-style state change. It does not receive a description of what the user switched to.
The time course: what happens to a Canvas session when you leave
Canvas's behavior depends less on the visibility signal alone and more on what the application does with it. Instructor-configured settings drive most of this. The table below describes the general sequence of events, not a specific institution's configuration.
| Time after leaving the tab | Browser behavior | Canvas-side outcome (typical, settings-dependent) |
|---|---|---|
| 0–2 seconds | Fires visibilitychange; state becomes "hidden" | Client registers that the tab is hidden |
| 1–30 seconds | Background timer throttling begins | Quizzes may stop auto-saving locally |
| 30 seconds–5 minutes | Throttling deepens; some timers coalesce | User status may switch to away or not, depending on setup |
| Around 15–30 minutes of inactivity | Session timeout thresholds commonly apply | Session may expire; you are logged out on return |
| On tab return | visibilityState becomes "visible" | Page may refresh, re-fetch, or resume; quiz timer reads server time |
| During a timed quiz | Server-side timer runs independently | Leaving the tab does not pause exam countdown |
The exact thresholds are not uniform. Session timeouts are usually set by the institution or identity provider, and many institutions use a standard single sign-on timeout. The visible effect of an inactive tab is that you may return to a login prompt or a page that needs a refresh.
The counterintuitive detail: in most scenarios, Canvas does not actively "watch" tabs in any special way. It reacts to a standard browser signal. The dramatic version of this question—can Canvas see your other tabs?—conflates visibility with surveillance. Those are different mechanisms with very different capabilities.
What Canvas can and cannot observe
A useful way to reason about this is to separate capabilities the browser grants to all pages from capabilities that would require permissions or privileged access.
The page can observe its own visibility state and focus changes. The page can measure the timing of user actions on its own document, such as mouse moves within the window and keyboard events. The page cannot read the contents of other tabs, even if the same browser is signed into the same account, unless the sites share a permitted mechanism. The page cannot read your clipboard without user gesture or permission. The page cannot access other applications, your screen, or your webcam without permission prompts. The page cannot see which website you switched to.
Canvas's acceptable-use and privacy posture is also relevant. What a vendor could technically log is constrained by what it chooses to log and what institutional configuration allows. The practical lesson is that the visibility signal is real, but it is not a window into your screen.
Why the difference between tabs and windows matters
Switching to another tab is one kind of hidden state. Minimizing the browser, switching to a full-screen application, or changing virtual desktop is another. All of these generally cause the same visibility change. From the page's perspective, the document is no longer visible.
There are nuances. Moving a window so that it is partially off-screen may not flip the state to hidden on all platforms. A tab that is visible but not focused—say, you clicked another window that overlaps it—still has visibilityState "visible" on many browsers, though the document may lose focus. The distinction matters for timing: focus events and visibility events are separate.
Another edge case: picture-in-picture video, split-screen, and multiple monitors. If a Canvas document remains visible on a second monitor while you work elsewhere, the browser may keep reporting "visible." Monitoring software that depends on visibility-only logic can misreport engagement in those setups.
Session timeouts, inactivity, and the 15–30 minute pattern
Inactivity handling is the mechanism users actually notice. Most learning platforms do not need visibility signals to expire sessions; they simply track last activity on the server. Switch away, stop interacting, and after an institution-set interval the session may end.
The conventional range is roughly 15 to 30 minutes of inactivity, though exact values are configured by the institution and its single sign-on provider. When you return and the session has expired, the next request redirects to login. That is not Canvas spying; it is standard session management.
Instructors and administrators configure some monitoring features independently. The point is that any visibility signal Canvas receives is one input among many, and timeouts typically operate on server-side activity timestamps.
Misconceptions worth retiring
Several claims circulate that deserve direct correction.
Claim: Canvas knows which website you opened. False. Visibility state is a binary signal; the browser does not report the destination. Claim: Canvas can see your screen. False. Screen capture requires explicit browser permission or dedicated software with consent. Claim: switching tabs in an unproctored quiz fails you automatically. Overstated. Unproctored assessments generally rely on the honor code and may not record visibility at all. Claim: the timer keeps counting because Canvas can tell you left. Partly confused. Timed assessments typically run a server-side clock that counts down regardless. Claim: incognito or a second browser defeats detection. Overstated. The same platform session and assessments of stability can produce conflicting signals.
Red-flag warnings for students, in bullet form:
Never assume an exam can be paused by switching tabs; timed assessments are typically server-timed. Do not attempt to game proctoring or monitoring tools; violations can carry academic consequences. Check whether your course uses proctoring software before assuming Canvas alone is involved. Expect session expiration after roughly 15–30 minutes of inactivity and re-authenticate promptly.
Plain-language version: the browser announces that you looked away. It does not narrate where you went.
When detection is by proctoring software, not Canvas itself
Many institutions use separate proctoring services embedded in or launched alongside Canvas. These tools are a different category from Canvas's own visibility signal. They may require permissions to monitor the screen, use webcam feeds, track focus changes, or flag tab switches. Their capabilities are set by the vendor and the institution's configuration, and the notice obligations vary.
This matters because advice about "Canvas seeing your tabs" often conflates the platform with the proctoring tool. A proctoring extension with permissions can do more than a standard web page. Neither a standard page nor a proctoring tool can do everything people imagine. Consultation with the institution's policy documents is the reliable way to know what applies in a given course.
One comparison: what the signals can detect
| Capability | Standard web page (Canvas) | Proctoring software | Screen recording / spyware on your device |
|---|---|---|---|
| Own tab visibility state | Yes | Yes | Yes |
| Focus changes on own document | Yes, within limits | Often instrumented | Yes |
| Identity of other tabs/sites | No | Generally no, unless permissions and tooling say otherwise | Varies; depends on the tool's permissions |
| Screen content | No | Sometimes, with explicit permissions | Often, if installed |
| Clipboard without permission | No | Varies | Varies |
| Webcam without permission | No | Requires permission/consent | Can, if installed |
| Other applications | No | Limited by platform permissions | Potentially yes |
Note the direction of the table: the standard page is the least capable actor, not the most. If a course requires proctoring software, that software's scope is defined by its permissions and institutional policy, neither of which is the same as Canvas's visibility event.
What you should actually do
The practical response depends on your role.
For students taking unproctored work: Keep a single browser tab for the assessment when possible. Do not rely on tab switching to pause a timer. Save your work at natural checkpoints if the page has a save control; visibility throttling can delay autosaves briefly. Locate your institution's session timeout policy, often stated in access or IT documentation.
For students taking proctored work: Read the proctoring instructions and permission prompts before starting. Confirm what the tool will monitor and whether you consent to it. Close personal applications only if instructed, and follow the course's rules exactly.
For instructors and support staff: Distinguish platform visibility signals from proctoring tool capabilities in any student-facing communication. Verify what your institution's configuration actually logs and retains. Document the timeout interval your system uses so students understand re-authentication behavior.
Threshold reconciliation, stated plainly: the common 15–30 minute session inactivity range is an institutional setting, not a universal Canvas limit. Browser timer throttling begins within seconds, but the effect on a given page depends on that page's code. Proctoring behavior is defined by the tool and its permissions. These are three separate clocks, and they should not be treated as one.
Limits of what can be concluded
The mechanisms described here are stable and documented browser behavior: visibility events, timer throttling, session management, and permission-gated device access. What changes is application behavior. Canvas's implementation, institution configuration, and proctoring tooling evolve, and the specific details of any course's setup are not established by general explanation alone.
For questions with academic or institutional consequences—exam rules, misconduct procedures, privacy rights—consult your institution's official policies and support staff rather than relying on general information. If a tool asks for permissions you are unsure of, pause and consult the course instructor or IT support before proceeding.