You can't see your cursor on Google Docs because the browser's text caret has stopped being drawn, not because the cursor has disappeared. The document still holds your insertion point; the thin vertical line or blink animation has simply dropped out of view. This happens when the caret blends into a colored background, when browser zoom or hardware acceleration corrupts its rendering, or when a browser extension intercepts focus. Google Docs draws its own caret on top of the browser's native one, and small failures in that overlay cause the cursor to vanish. In most cases a single page reload restores it, and failing that, one specific accessibility setting brings it back permanently.
How Google Docs draws a cursor
Google Docs does not rely on the ordinary text caret of the browser. It uses a canvas-based rendering layer that paints the document, the selection, and the blinking insertion line. The browser supplies only a hidden or nearly hidden native caret, and Google overlays its own drawing so the cursor stays consistent across fonts and layout changes. This design is why the caret can vanish independently of the rest of the page: if the overlay fails, the text still renders and you can still type, but nothing marks where the next character will land.
The caret blinks on a timer. Each cycle turns it visible and invisible, and the browser repaints that small region. When the repaint is delayed or dropped, the caret can stay invisible for longer than the off phase of the blink. Rapid typing, a slow machine, or a throttled background tab increases the chance that a repaint is skipped. The document's own focus state matters too: if a dialog, an extension popup, or the browser chrome takes focus, the caret stops drawing until focus returns to the editable area.
Accessibility settings change this behavior. Browsers expose options to thicken or widen the text cursor, and Google's own settings include a caret visibility aid. Those settings often restore a caret that the rendering layer failed to paint, because the browser falls back to a drawn native caret. That fallback is why turning on a wider caret solves a surprising share of cases.
Quantified context
A few thresholds predict when the caret is likely to vanish. Browser zoom above 100% forces the canvas to rescale text and caret geometry, and rendering glitches cluster around 125%, 150%, and 175% zoom levels. Below 50% zoom the caret line can narrow to a fraction of a pixel and fade against the text. Both extremes are worth testing before anything else.
Hardware acceleration is the single most common culprit in reports of a missing caret. When a GPU driver mishandles the compositing layer, the caret's small repaint can be lost while the rest of the document updates. Disabling acceleration in the browser settings fixes a large fraction of these cases.
Extensions are the second leading cause. Ad blockers, page restylers, screen readers, and grammar tools that inject content into the page can intercept the focus or restyle the caret. Testing in an incognito window, where extensions are disabled by default, isolates this cause within a minute.
Memory and CPU pressure matter at the margins. A tab using several hundred megabytes, or a machine running near its memory ceiling, throttles the small repaints the caret needs. Large documents above roughly 50 pages and documents with hundreds of suggestion marks multiply the repaint work, which raises the odds the caret is skipped.
Edge cases
Dark mode and custom themes are a frequent source of an invisible caret. The caret takes its color from the document theme, and a theme that sets the caret to the same value as the page background renders it invisible while the text remains readable. High-contrast browser modes and forced-color modes can produce the same collision.
The caret also disappears when focus is lost. Clicking the toolbar, opening the comments pane, or pressing a keyboard shortcut that opens a dialog moves focus off the editable area. The document still shows your selection, so it looks as if the cursor vanished, when in fact the editor is simply not focused.
Remote and shared sessions add another layer. In a collaborative session the caret may be drawn for a co-editor but not for you, or a suggestion overlay can paint on top of your insertion line. Printing or exporting to PDF uses a separate renderer and never shows the on-screen caret, which confuses people who compare the two.
A professional caveat: the caret can be invisible while text selection still works perfectly. If shift-arrow and double-click select text correctly, the issue is drawing, not data. Treat it as a display fault to fix, not a document fault to panic about.
What people get wrong
The most common misconception is that the document has lost your place. Clicking around to "find" the cursor often changes the insertion point and inserts text in the wrong location. If you can type and the characters appear where you intended, the insertion point was never lost.
A second error is blaming the document itself. A single document that hides the caret usually points to theme or formatting, while every document that hides the caret points to browser or extension. Testing a second document separates these two cases quickly.
A third mistake is reinstalling the browser. Most caret faults are configuration-level and resolve with a setting change. Reinstalling rarely helps and costs time.
A fourth is assuming spellcheck or grammar tools are safe. Those tools inject overlays into the editable page and are a documented cause of focus and caret faults. Turning them off for one test is faster than a full reinstall.
A caret that is invisible but typing works: a drawing fault, not lost position. A caret missing only in dark mode: caret and background colors have collided. A caret missing after opening a dialog: the editor lost focus. A caret missing only with extensions on: an extension is intercepting focus. A caret flickering rather than vanishing: repaint throttling under load.
Fixes compared
| Fix | What it targets | Typical effort | Success when it helps |
|---|---|---|---|
| Reload the page | Transient repaint or focus fault | Seconds | Very high for one-off glitches |
| Incognito test | Extension interference | Under a minute | High when an extension is the cause |
| Disable hardware acceleration | GPU compositing fault | Minutes, needs restart | High on machines with driver issues |
| Widen the text caret setting | Rendering fallback fails | Minutes, one-time | High and permanent |
| Reset zoom to 100% | Scaling glitch | Seconds | Moderate at non-default zoom |
| Disable conflicting extension | Focus interception | Minutes | High once the culprit is found |
Practical actions
Work from least disruptive to most. Each step isolates one cause, so you stop as soon as the caret returns.
Click once inside the document body, then reload the page. This restores focus and clears transient repaint faults. Press Ctrl+Shift+R on Windows or Cmd+Shift+R on a Mac to force a full reload that bypasses cache. Reset browser zoom to 100% with Ctrl+0 or Cmd+0, then test at the default level. Open the same document in an incognito window. If the caret appears, an extension is responsible; disable extensions one at a time to find it. Turn on the browser's text-caret width setting, often found under accessibility settings, and widen it by one or two steps. Disable hardware acceleration in browser settings, restart the browser, and retest. Switch to a second browser as a confirmation test. If the caret appears there, the original browser's profile or settings are the cause. If the caret is missing only in dark mode, change the document theme or switch to light mode to confirm the color collision.
Stop at the first step that restores the caret, and note which one worked so you can apply it directly next time.
Limitations
Some caret faults are server-side or account-side and cannot be fixed locally. If the caret is missing across every document, every browser, and every device on the same account, the fault likely sits in the account's settings or in a Google-side rendering change. In that case, report it through the document's help menu, because a local fix will not hold.
Two thresholds deserve reconciliation. A zoom problem is worth fixing when the caret is missing only at one zoom level but fine at 100%; a hardware-acceleration problem is worth fixing when the caret is missing at every zoom level but returns with acceleration off. If both tests pass and the caret still vanishes, extensions and account settings are the remaining candidates.
The deeper limitation is diagnosability. The caret is drawn by a compositing layer you cannot inspect from the page, so there is no reliable way to confirm the cause from the interface alone. The steps above narrow the cause by elimination rather than by direct measurement. That is why the incognito and second-browser tests are valuable: they are controlled comparisons, not guesses.
What the evidence supports is a short list of common causes and a reliable order of fixes. What it does not support is a single universal fix, because the fault sits at different layers in different setups. When local steps fail, the honest next move is to report the issue with the browser version and zoom level attached, not to keep reinstalling software.