Jump straight to your symptom:
| Symptom | Usually caused by | Section | |---|---|---| | Notebook won't open / stuck on loading screen | Cache, extension, or outage | Notebook Won't Open or Load | | PDF or file upload fails or hangs | Size/word limit, unreadable text, or extension | PDF and File Upload Failures | | PDF uploads but AI can't answer about it | Scanned PDF with no text layer | OCR and Scanned PDF Problems | | YouTube video won't import | Private, no captions, no speech, or too new | YouTube Import Errors | | Website import missing content | Paywall, JS-heavy page, or nested pages | Website Import Errors | | Google Doc/Slides source is outdated or won't import | Access revoked, sync lag, or slide count | Google Docs and Slides Import Problems | | Audio/Video Overview fails or won't play after download | Daily quota or interrupted generation | Audio Overview and Video Overview Failures | | "The system was unable to answer" | Request too large or complex | Chat Not Responding or Giving Bad Answers | | Everything feels slow or times out | Large notebook, network, or peak load | Slow Performance and Timeouts | | Share button missing / can't add a collaborator | Ad blocker hiding UI, or org restrictions | Sharing and Collaboration Problems | | "Try again later" / daily limit reached | Rate limit for your plan | Rate Limits and Daily Quota Errors |
I've spent enough hours poking at NotebookLM's failure modes — deliberately uploading files that should break it, testing what happens when a shared team notebook blows through its daily quota mid-meeting, tracking down why a Share button vanished on one machine and not another — that I've stopped assuming any given error is a mystery. Almost everything below has a specific, identifiable cause. Where it doesn't — where Google hasn't documented the behavior and I can't verify it from a reliable source — I say that explicitly instead of guessing, which is more than most of the coverage on this topic bothers to do.
For the product basics, see the Complete NotebookLM Guide. For the exact numbers behind most of the limit-related problems here, see NotebookLM Source Limits (2026) — this guide focuses on diagnosis and fixes, not re-deriving those numbers.
Do this before anything else, because it determines whether the rest of this guide is even useful to you right now.
If the Status Dashboard is clean and the problem reproduces in incognito on a fresh notebook, you're dealing with a real, specific issue — proceed to the relevant section below.
{/ TODO: Screenshot of the Google Workspace Status Dashboard showing Gemini Notebook status /}
Why it happens: NotebookLM is a single-page web app — the whole interface loads as one JavaScript bundle, and anything that interferes with that (a stale cache, a corrupted cookie, a script-blocking extension) can leave you staring at a spinner or a blank page indefinitely rather than a clean error message. A genuinely large notebook (many sources, long chat history) can also just take longer to hydrate than you'd expect, especially on a slow connection.
How to diagnose it: - Confirm it's not a Google-side outage first. - Try incognito. If it loads there, it's a local cache or extension problem. - Try a completely different notebook. If only one specific notebook is stuck, the notebook itself (its size, or a specific source inside it) is more likely the cause than your browser.
How to fix it: 1. Hard refresh the page (Ctrl+Shift+R / Cmd+Shift+R) before anything else — this alone resolves a surprising number of stuck-loading reports. 2. Clear cookies and cached data specifically for the site. Note that the product's URL moved from notebooklm.google.com to notebook.google.com, so if you're clearing site data manually by domain, make sure you're clearing the current one. 3. Disable extensions one at a time (see Extension Conflicts below for the systematic approach) rather than guessing which one is responsible. 4. If it's one specific large notebook that's slow rather than every notebook, give it more time before assuming it's broken — very large notebooks can take noticeably longer to open than a fresh one.
When there's no fix: If the Status Dashboard confirms an active incident, waiting is the only real option. Don't spend an hour clearing caches and disabling extensions for a problem that's happening on Google's end.
Why it happens: Upload failures cluster around four root causes, and they're worth checking in this order because it's roughly the order of likelihood:
How to diagnose it: - Check the file's actual size and, for text documents, try selecting text in a PDF viewer — if you can't select any text, you have an OCR problem, not an upload problem. - Test the same upload in an incognito window. If it succeeds there, an extension was blocking it. - If several unrelated uploads all fail around the same time, suspect a temporary server issue rather than anything about your specific files.
How to fix it: - Oversized files: split by chapter or section rather than trying to compress your way under the limit for genuinely long documents. The large PDFs guide covers this in depth, including a free, browser-based Sourclip PDF Splitter that splits by page range without uploading your document to any server. - Non-extractable text: run it through OCR first — see the next section. - Extension interference: disable ad blockers and privacy extensions for the site, or complete the upload in incognito mode where most extensions don't run by default. - Corrupted or copy-protected files: if the file is intentionally locked (DRM'd), removing that protection is a separate problem outside NotebookLM's control — you'll need the source in an unprotected format before it can be a source at all.
{/ TODO: Screenshot showing the "error uploading source" message in NotebookLM /}
Why it happens: NotebookLM reads a PDF's text layer — the invisible, selectable text underneath what you see. A scanned or photographed document is an image of text with no text layer beneath it, so there's genuinely nothing to index. This isn't a bug or an edge case Google has quietly failed to handle; it's a real capability gap, and Google's own troubleshooting guidance confirms sources without readable text won't produce useful answers. Critically, this fails silently in a specific way: the upload often succeeds, and the source appears in your notebook looking completely normal — the failure only shows up when you ask the AI a question and it can't answer from a document you can clearly see is right there.
How to diagnose it: Open the PDF in any viewer and try to select text with your cursor. If nothing highlights, there's no text layer, and that's your answer.
How to fix it: 1. Upload the scanned PDF to Google Drive. 2. Right-click it and choose "Open with Google Docs" — Google automatically runs OCR when it converts a scanned PDF to a Doc. This is free and requires no extra tools. 3. Download the result as a PDF (File → Download → PDF Document), which now has a real text layer. 4. Upload that converted file to your notebook instead of the original scan.
For faster or higher-accuracy OCR on poor-quality scans (handwriting, low-resolution photos, unusual fonts), a dedicated OCR tool will generally outperform the Google Drive trick — but for the average scanned textbook chapter or printed document, Drive's built-in OCR is good enough and costs nothing.
When there's no fix: Badly degraded scans — very low resolution, heavy skew, handwritten text in an unusual hand — can produce OCR output too garbled to be useful even after conversion. At that point the realistic options are re-scanning at higher quality or manually transcribing the relevant sections.
Why it happens: NotebookLM imports a video's caption transcript, not the video file itself, which means the failure modes are about caption and visibility requirements rather than video length or quality. Four specific requirements have to all be true:
There's no hard duration limit in the way people expect; the practical ceiling is that the caption transcript itself can't exceed 500,000 words, which essentially never happens for a normal-length video. Full detail on this is in the source limits guide.
How to diagnose it: Check each of the four requirements above individually — NotebookLM's error messaging doesn't always tell you which one you're failing. Open the video on YouTube directly and confirm: is it public, does it show a CC/captions option, does it have audio, and when was it uploaded.
How to fix it: If captions are missing and you control the video, add them on YouTube first. If the video is private or unlisted and you don't control it, there's no workaround — you'd need permission to use it publicly, or to source the content another way. If it's simply too new, wait a day or two and try again.
When there's no fix: A video that's permanently private, has no captions and never will, or genuinely contains no speech (a silent screen recording, for instance) cannot be imported as a source, full stop. There's no paid tier or workaround that changes this — it's a structural requirement of how the import works.
Why it happens: NotebookLM's website importer scrapes only the visible text content of a page — it doesn't render images, embedded videos, or nested/linked pages, and it explicitly doesn't support paywalled content. Two distinct failure patterns come from this: pages behind a login or subscription wall fail outright, and JavaScript-heavy pages (where content loads dynamically rather than existing in the initial HTML) can import incompletely, missing exactly the content you wanted.
How to diagnose it: If the page requires any login or subscription to read the full article, that's your answer — paywalled content isn't supported. If the page is accessible but the imported source seems to be missing large chunks of visible content, suspect a JavaScript-rendering issue rather than a paywall.
How to fix it: For JS-heavy or dynamically-loaded pages, converting the page to clean text yourself before adding it as a source tends to be more reliable than the built-in importer. Sourclip's Webpage to Markdown tool does this conversion for free in the browser — paste the URL, get clean text back, and add that as a text source instead of relying on the native URL import. For paywalled content, there's no real workaround inside NotebookLM itself; you'd need to access the full text through a legitimate subscription and paste it in as a text source manually.
When there's no fix: Content you don't have legitimate access to read in full isn't something any import method should bypass, and we're not going to suggest one.
Why it happens: Drive-sourced imports have their own layer of rules on top of the general word/file limits. You need at least Viewer access to import a file at all — Editor isn't required, but view-only access is the floor. If your access to the original file is later revoked, or the file is deleted, the source in your notebook becomes inaccessible; NotebookLM doesn't keep an independent copy once it loses the connection to a live Drive file it's syncing against. Google Slides has an additional hard cap of 100 slides per source — a larger deck needs to be split or trimmed before it will import.
One subtler behavior worth knowing: NotebookLM pulls in content from multiple tabs within a single Doc or Sheet as one combined source, but content in sub-tabs (nested under a tab) is not imported — if your document uses that structure and content seems to be missing, that's very likely why.
How to diagnose it: - Confirm you still have at least Viewer access to the original file in Drive. - If the source looks stale (showing old content), it's a sync-lag issue, not an access issue — see below. - If a Slides import fails outright, count the slides; over 100 will fail the import.
How to fix it: - Stale content: Drive-imported sources are supposed to auto-sync every few minutes, but sync can lag. Select the source in your notebook's source list and look for a "sync with Google Drive" link near the title — clicking it forces an immediate refresh instead of waiting. - Access revoked: re-share the file with at least Viewer permission, then the source should reconnect. - Slides over 100 slides: split the deck into two files, or trim it down to the sections actually relevant to your notebook. - Missing footnotes or comments: this isn't a bug to fix — NotebookLM doesn't import footnotes or comments from Google files at all, by design. If that content matters, copy it manually into a text note.
Why it happens: Generation failures split into two very different categories that are worth distinguishing. The first is quota-related — you've hit your plan's daily Audio or Video Overview limit (3 to 200 a day depending on tier; the full table is in the source limits guide) and the generation simply won't start. The second is a generation-process failure — the request starts but the output never finishes cleanly, sometimes producing a file that downloads but won't play in a media player, which usually indicates the file didn't finish encoding or the download was interrupted partway through.
How to diagnose it: If generation fails to start at all, check whether you've hit your daily quota first — this is the more common cause and the easiest to rule out. If it starts, runs, and produces a file that then fails to play, that's a download/encoding issue rather than a quota issue.
How to fix it: - Quota hit: wait for the daily reset (24 hours from when you started using the quota, per Google's documentation) or upgrade — see NotebookLM Pricing for what each tier actually raises this to. - File won't play after download: re-download it once — a partial or interrupted download is a common, boring explanation. If the re-download also fails to play, regenerate the Audio or Video Overview from scratch rather than continuing to re-download a file that may not have encoded correctly the first time. - Generation seems stuck mid-process: give it a few minutes before assuming it's failed — Audio and Video Overviews, especially Cinematic ones, are genuinely compute-intensive and can take longer than a normal chat response.
For getting a completed Audio Overview out in a more portable format than the native download, see the export guide.
Why it happens: Two distinct error patterns show up here, and they mean different things.
"The system was unable to answer" tends to happen when a single question asks for too much at once — synthesizing across a very large or complex source set in one request. It's a capacity/complexity failure, not a content problem.
"Gemini Notebook can't answer this question" is a different, deliberate behavior: chat responses only use data from your sources, by design — it's the entire premise of the product. Asking for something that requires knowledge or creativity outside your uploaded material (a creative rewrite unrelated to your sources, a general-knowledge question your sources don't cover) will hit this response, and no amount of retrying changes that. It's not a bug; it's the source-grounding design doing exactly what it's supposed to.
How to diagnose it: If you got the "unable to answer" message on a broad, multi-part question, that's the complexity pattern. If you got "can't answer this question" while asking for something not actually contained in your sources, that's the by-design scope limit, not an error.
How to fix it: - "Unable to answer": retry the exact same prompt once — it sometimes succeeds on a second attempt. If it fails again, break the question into two or three smaller, more specific questions rather than one broad one. See NotebookLM research workflows for prompting patterns that work with this constraint instead of against it. - "Can't answer this question": reframe the request to work within your sources, or add the missing material as a new source if it's something you're allowed to include. - Vague or generic answers on a large notebook (not an outright error, just weak output): this is usually a source-count issue rather than a chat bug — narrow your question, pin the most relevant sources, or split an overly broad notebook by sub-topic. Full detail in the source limits guide's performance section. - Garbled or confused answers from a specific source: if that source came from a messy paste (a ChatGPT export, PDF-extracted text with broken formatting), the noise itself may be the problem rather than anything about chat. Running it through Sourclip's Markdown Cleaner before adding it as a source tends to produce more reliable citations.
Why it happens: Genuine slowness has a few honest, non-mysterious causes: a notebook with a very large number of sources or a long chat history taking longer to process each request, too many open tabs or a heavy browser session generally, an unstable network connection, or — during periods of unusually high demand — the kind of latency any cloud AI product experiences under peak load. Reports of chat performance issues have led Google to make backend improvements over time, but that doesn't mean every instance of slowness is fixed permanently; it fluctuates.
How to diagnose it: Rule out the Google-side outage check first. Then check whether it's one specific large notebook that's slow, or everything — the former points to notebook size, the latter points to your connection, browser load, or a broader service issue.
How to fix it: - Close unused browser tabs, especially other heavy web apps competing for the same resources. - Test on a different, more stable network if you suspect connectivity. - For a specific large notebook, consider whether it's grown past the point of being one coherent project — splitting it isn't just a performance fix, it usually produces better-cited answers too. - Clear chat history for a notebook (three-dot menu → Delete Chat History) if a very long conversation seems to be part of the slowdown — this is a documented, supported action, not a workaround.
When there's no fix: Peak-load latency during unusually high demand periods isn't something you can troubleshoot away locally — it resolves when demand normalizes.
NotebookLM is built as a modern web app and is generally reported to work across Chrome, Firefox, Safari, and Edge, provided the browser is reasonably up to date. That said, a few things are worth knowing:
Why it happens: Any browser extension that modifies a page's scripts or blocks network requests can interfere with a JavaScript-heavy web app like NotebookLM — and this is one of the most under-diagnosed causes of "random" bugs, because the failure looks like it's coming from NotebookLM when it's actually coming from something injected alongside it. Ad blockers, privacy/tracking-protection extensions, and VPN extensions are the most frequently reported offenders, and they typically fail silently — no warning, no error message pointing at the extension, just a broken upload or a missing UI element.
How to diagnose it: This is the same incognito test from earlier in this guide, applied specifically: open NotebookLM in an incognito/private window (most extensions are disabled there by default unless you've explicitly allowed them). If the problem disappears, an extension is responsible, and the systematic way to find which one is:
For the landscape of what's actually available and generally well-behaved in this space, see the Chrome extensions guide.
Get clean captures, workspace management, reusable prompts, and easy exports.
Add Sourclip to ChromeTwo genuinely different things get called "sync issues," and it's worth separating them.
Drive-sourced content (Docs, Sheets, Slides) has documented sync behavior: auto-updates every few minutes, with a manual "sync with Google Drive" link available on the source if you don't want to wait — covered in detail in the Google Docs and Slides section above.
Multiple browser tabs or devices showing different states — one tab not reflecting a change made in another — is a more general web-app behavior rather than something specific to NotebookLM that Google documents separately. Like most single-page apps, a tab that's been open a while can hold onto stale state until it's refreshed. If two tabs or devices seem out of sync, a manual reload of the older one is the practical fix; we couldn't find official documentation describing this as a known issue with its own dedicated fix, so treat this as general web-app hygiene rather than a NotebookLM-specific bug you should expect a special fix for.
Missing Share button: the most commonly reported cause is an ad blocker or privacy extension hiding part of the interface, not an actual permissions issue — see the extension conflicts section for the fix (allowlist notebook.google.com).
Can't find or add a specific person in the Share dialog: this has been reported to happen when you haven't previously shared any Google Drive file with that person — NotebookLM's people-picker appears to rely on the same suggestion system Google Drive uses elsewhere, which surfaces people you've shared with before more reliably than people you haven't. Sharing any file with that person first (even something unrelated) has been reported to resolve this.
"Outside organization" or similar sharing restrictions: if you're on a work or school Google account, your Workspace administrator may have organization-wide settings that restrict sharing outside your domain — this isn't a NotebookLM bug, it's the same admin-controlled policy that affects Docs and Drive sharing generally. If you hit this on a managed account, the fix requires your Workspace admin adjusting the sharing policy, not anything you can change from inside NotebookLM. This is the kind of restriction professionals managing client or team notebooks on a work account run into most.
NotebookLM Enterprise specifically has its own separate sharing requirements (same Cloud project, appropriate IAM role, same workforce pool, valid Enterprise license) that don't apply to consumer accounts — if you're on Enterprise and sharing fails, the cause is almost certainly one of those, and the fix runs through your organization's Cloud admin rather than general troubleshooting.
Why it happens: Every plan has daily limits on chats and generated artifacts (Audio Overviews, Video Overviews, Reports, Flashcards, Quizzes, and Mind Maps), plus a monthly (Free) or daily (paid) Deep Research allowance. These exist for the same reason any AI product rate-limits usage: inference costs money, and an unrestricted free tier isn't sustainable — the full reasoning and exact numbers are in the source limits guide.
How to diagnose it: If chat or generation suddenly stops working partway through a session with no other symptoms — no loading issues, no extension conflicts, works fine on a different notebook — a daily limit is the most likely explanation, especially if you've been using the notebook heavily that day.
How to fix it: There isn't a way to pay for a one-time overage. Your real options are waiting for the quota to reset (24 hours for daily limits, 30 days for the free tier's Deep Research allowance) or moving to a plan with higher daily ceilings — see NotebookLM Pricing (2026) for exactly what each tier raises this to. This is the wall students hit hardest during exam-week cramming sessions, and the practical move there is often just working in shorter, spread-out sessions rather than one marathon session that burns the whole day's quota by early afternoon.
When there's no fix: If you've genuinely hit your plan's ceiling, there's no local troubleshooting step that changes that — it's working exactly as designed.
| Message | What it actually means | Fix | |---|---|---| | "The system was unable to answer" | Request too broad or complex for one response | Retry once, then split into smaller questions | | "Gemini Notebook can't answer this question" | You asked for something outside your sources | Reframe within sources, or add the missing source | | Upload fails with no specific error | Extension blocking the request, or size/format issue | Test in incognito; check file size and text extractability | | Source uploads but chat can't reference it | Likely a scanned PDF with no text layer | Run OCR before uploading, see above | | Generic "try again later" on chat or generation | Daily quota reached | Wait for reset or upgrade |
The clearest tell: multiple unrelated actions fail around the same time — uploads, chat, and generation all acting up simultaneously, across different notebooks, in incognito mode, on a stable connection. That pattern points away from anything you did and toward infrastructure. Google has posted real service disruptions affecting Audio Overview and Video Overview generation specifically in the past, tracked through the Workspace Status Dashboard — this isn't hypothetical; it happens periodically like any large cloud service.
When this is the case, the most useful thing you can do is exactly nothing, locally — no amount of clearing cache or disabling extensions fixes a server-side problem, and burning an hour on local troubleshooting for an outage is wasted effort. Check the Status Dashboard periodically, or simply try again in twenty or thirty minutes.
Before submitting feedback to Google, work through this in order — it takes a few minutes and dramatically increases the odds your report actually leads to a fix, rather than getting lost as an unreproducible one-off:
{/ TODO: Screenshot of the Settings → Send Feedback flow inside NotebookLM /}
For the numbers behind most of the limit-related issues here, see NotebookLM Source Limits (2026). For what the rebrand did and didn't change, see NotebookLM Is Now Gemini Notebook. For extending what NotebookLM can do beyond its native tools, see the Chrome extensions guide.