# NotebookLM Supported File Types: Allowed Formats and Workarounds A practical guide to NotebookLM supported file types, upload limits, and format workarounds. Google NotebookLM natively supports documents, presentations, audio recordings, web links, and YouTube video transcripts within strict source boundaries. While PDF, Google Docs, Markdown, and MP3 files upload directly, raw spreadsheets and multi-file codebases require pre-processing or external indexing to ground AI responses accurately. Source: https://fast.io/resources/notebooklm-supported-file-types/ Author: [Tom Langridge](https://fast.io/authors/tom-langridge/) Last reviewed: 2026-10-12 ## What File Types Does NotebookLM Support Natively? Google NotebookLM caps each uploaded source document at 500,000 words or 200MB, limits free accounts to 50 total sources, and rejects direct uploads of raw Excel workbooks (.xlsx), disk archives, or audio files without clear speech. Knowing which file types pass validation on first upload prevents broken citations, corrupted tables, and stalled research sessions. When teams understand exact format boundaries in advance, they avoid spending hours converting unsupported assets mid-project. NotebookLM natively supports PDF, Google Docs, Google Slides, plain text (.txt), Markdown (.md), audio files (MP3, WAV, M4A, AAC), copied text, web URLs, and public YouTube video URLs. Google also accepts Microsoft Word (.docx), PowerPoint (.pptx), CSV (.csv), ePub files, static images, and token-bounded Google Sheets through its Gemini Notebook interface. Each format enters an ingestion pipeline that strips styling, extracts raw textual content, and generates semantic embeddings for retrieval-augmented generation. ``` +-------------------------------------------------------------------------+ | Google NotebookLM Native Ingestion Engine | +-------------------------------------------------------------------------+ | +-----------------------+-----------------------+ | | v v +-------------------------+ +-------------------------+ | Directly Supported | | Unsupported / Gated | |-------------------------| |-------------------------| | - PDF (.pdf) | | - Excel (.xlsx) | | - Google Docs & Slides | | - Audio without speech | | - Plain Text & Markdown | | - Private YouTube links | | - Audio (MP3, WAV, M4A) | | - Git repos / folders | | - Word & PowerPoint | | - Password-locked PDFs | | - Web & YouTube URLs | | - Large Sheets > limits | +-------------------------+ +-------------------------+ ``` The table below outlines the primary input formats, their native support status, operational size ceilings, and key ingestion rules. | File Type / Input Format | Native Status | Maximum Limit | Ingestion Mechanism & Behavior | |---|---|---|---| | PDF (.pdf) | Supported | 200MB or 500,000 words | Text and tables parsed into vector chunks; encrypted files fail | | Google Docs | Supported | 500,000 words | Imported from Google Drive; periodically polls for updates | | Google Slides | Supported | Up to 100 slides | Text extracted from presentation slides; speaker notes parsed | | Plain Text (.txt) & Markdown (.md) | Supported | 200MB or 500,000 words | Ingested directly as structured text without formatting loss | | Microsoft Word (.docx) & PowerPoint (.pptx) | Supported | 200MB or 500,000 words | Modern XML formats parsed; legacy binary (.doc, .ppt) require conversion | | CSV (.csv) & Google Sheets | Partial Support | Token-limited (Sheets) | Ingested as plain tabular text; formula execution is not supported | | Microsoft Excel (.xlsx) | Unsupported | Requires conversion | Direct upload blocked; must convert to CSV, Google Sheets, or PDF | | Audio Files (MP3, WAV, M4A, AAC, OPUS) | Supported | 200MB file size | Transcribed to text upon import; spoken voice required | | YouTube Video URLs | Supported | Up to 500,000 words in transcript | Scrapes video captions; public videos only; no raw video parsing | | Webpage URLs | Supported | 500,000 words | Scrapes visible HTML body text; paywalled or login-gated sites fail | | Static Images (PNG, JPG, WEBP, GIF, HEIC) | Supported | 200MB | Text and visual elements extracted through multimodal vision models | | Codebases / Git Repositories | Unsupported | Requires bundling | Directory structures rejected; files must be merged into text/markdown | ### Core Text and Document Ingestion Rules Text documents form the backbone of most NotebookLM research projects. When you upload a PDF, Word document, or Markdown file, NotebookLM extracts raw textual content, strips away visual styling, and splits the prose into discrete semantic chunks for vector retrieval. PDF files must contain selectable text. If you upload a scanned document where pages consist solely of raw bitmap images without an embedded text layer, NotebookLM attempts basic text recognition, but complex layouts, multi-column reports, and faded scans frequently suffer retrieval errors. Furthermore, copy-protected or password-encrypted PDF files fail to import entirely. Word documents must use the modern Office Open XML format (.docx). Legacy Microsoft Word binary files (.doc) created before Office 2007 cannot be parsed and will trigger an immediate file type error in the upload modal. Google Docs imported through Google Drive retain a live reference link. When a team member edits a connected Google Doc, NotebookLM checks Drive on a periodic background schedule. You can also force an immediate refresh by opening the document viewer in NotebookLM and clicking the manual sync button. In contrast, local files uploaded from your desktop remain frozen snapshots captured at the exact moment of upload. When choosing [Google Drive alternatives](/alternatives/google-drive/) for team storage, evaluating how external tools sync revisions is critical for keeping research current. ### Source Capacity Across Plan Tiers Individual documents are governed by a strict ceiling of 500,000 words or 200MB per file. While 500,000 words is large enough to accommodate an entire academic dissertation or technical handbook, the operational bottleneck for most teams is the total source count per notebook. Free accounts can link up to 50 sources per notebook. Paid Google workspace and consumer tiers (such as Gemini Plus, Pro, and Ultra subscriptions) raise this threshold to higher allowances depending on the subscription level. Because inactive or deselected sources continue counting against your total source allocation, teams running extensive research projects frequently hit the 50-source wall. When that occurs, you must either consolidate existing documents into larger digest files, split research across separate notebooks, or transition to an external workspace designed for large document archives. ## How Does NotebookLM Process Audio Files and YouTube URLs? Many users assume NotebookLM listens to audio tracks or watches video frames dynamically during chat reasoning. In reality, NotebookLM operates strictly on text representations. Understanding how audio and video inputs are converted into text reveals why certain multimedia files succeed while others fail without obvious error messages. When you submit a multimedia source, NotebookLM routes the input through specialized speech-to-text models or caption scrapers before grounding queries. Because language models process text tokens rather than raw waveforms or pixel frames, every spoken word must be transcribed accurately. Incomplete transcripts, background noise, or missing subtitles directly degrade the quality of generated answers. ### Audio File Upload Mechanics and Speech Requirements Audio File Upload Mechanics and Speech Requirements govern multimedia inputs. NotebookLM accepts audio files up to 200MB across a broad range of containers, including MP3, WAV, M4A, AAC, OGG, OPUS, AMR, AIFF, and WMA. However, the system does not index the audio waveform itself. The audio file is transcribed at the time of import and its text is saved to use as a new source. Once transcription finishes, the original audio file is no longer queried during chat sessions; the language model references only the generated transcript. This architectural pattern introduces three critical constraints: * **Clear Human Speech Is Mandatory:** Audio files containing only instrumental music, nature sounds, ambient background noise, or sound effects are rejected during processing. The ingestion pipeline requires audible human dialogue. * **Transcription Quality Bounds Retrieval:** If a recording features heavy reverberation, low bitrates, loud background noise, or multiple overlapping speakers, the resulting transcript will contain phonetic misinterpretations. Because the model grounds its answers strictly on the transcript text, transcription errors directly cause hallucinated or missing answers. * **Word Count Ceilings Apply to Transcripts:** Even if an audio file is under the 200MB upload limit, the transcribed text cannot exceed the standard 500,000-word source cap. For typical spoken speech, 500,000 words represents dozens of hours of continuous audio, making file size rather than word count the primary boundary for audio uploads. ### YouTube Transcript Parsing and Lifecycle Constraints Adding a YouTube video to NotebookLM requires entering a public video URL. NotebookLM does not download the video stream, decode video frames, or run computer vision across presentation slides. Instead, it extracts the video's closed caption track and stores the text as a source. To successfully import a YouTube URL, the video must meet strict operational criteria: * **Public Access Only:** The video must be set to public. Private videos cannot be accessed by Google's extraction service. Unlisted videos often fail validation depending on account permissions. * **Closed Captions Must Exist:** The video must have either human-uploaded captions or auto-generated subtitles. If a video lacks captions entirely, NotebookLM will reject the URL with an error stating that no transcript is available. * **The 72-Hour Propagation Window:** For newly uploaded YouTube videos, automated caption generation can take several hours or days to process on YouTube's backend. Attempting to add a video within 72 hours of publication frequently fails because the caption file has not yet propagated across Google's services. * **Lifecycle and Deletion Rules:** NotebookLM maintains a lightweight check on connected YouTube links. If the original video is deleted, made private, or removed from YouTube, NotebookLM automatically purges the corresponding source from your notebook within 30 days. ## Why NotebookLM Struggles With Spreadsheets and Tabular Data Data analysts, project managers, and operations teams frequently attempt to upload financial spreadsheets, inventory logs, customer metrics, and structured survey results into NotebookLM. While Google has introduced support for CSV files and token-restricted Google Sheets, tabular data remains one of the most challenging formats for text-based retrieval systems. The core issue stems from how language models interpret tabular geometry. Standard text documents flow sequentially from left to right and top to bottom, allowing retrieval systems to extract coherent paragraphs and clean semantic ideas. Spreadsheets, by contrast, rely on strict two-dimensional coordinates where individual data points derive meaning exclusively from distant header rows and column intersections. When these spatial relationships are flattened into plain text, the underlying context easily fragments, leading to retrieval errors and hallucinated calculations during chat sessions. ### Token Ceilings and the RAG Chunking Problem The primary technical barrier with spreadsheets lies in how Retrieval-Augmented Generation (RAG) systems ingest documents. Text splitters segment documents into sequential chunks of several hundred tokens, adding a small overlap between adjacent blocks. This chunking method works well for narrative prose, where paragraphs retain self-contained meaning. In a structured spreadsheet, however, meaning is distributed across orthogonal rows and columns: ``` Spreadsheet Chunking Breakdown: Row 1 (Headers): | Region | Account ID | Status | Category | ... Row 48: | EMEA | ID-8921 | Complete | Hardware | [=== Chunk Boundary Split Occurs Here ===] Row 49: | APAC | ID-9014 | Pending | Software | Row 50: | APAC | ID-9102 | Active | Services | ``` When a chunker slices a spreadsheet halfway through its rows, rows 49 and 50 are separated from the column headers on row 1. When the language model retrieves the second chunk to answer a query, it sees isolated text without knowing whether a retrieved string represents customer category, department name, or fulfillment status. Furthermore, Google limits Google Sheets sources to specific token thresholds. A medium-sized enterprise ledger containing tens of thousands of rows will easily surpass this ceiling, resulting in rejected uploads or severe data truncation. ### Mathematical Reasoning Versus Text Retrieval Language models are probabilistic text predictors rather than deterministic calculation engines. NotebookLM does not execute SQL queries, calculate formulas, or run relational joins across spreadsheet rows. When you ask a question like "What was the total order count across European accounts in Q2?", NotebookLM scans its retrieved text chunks for mentions of European accounts and attempts to synthesize an answer in natural language. If the spreadsheet contains hundreds of rows, the model cannot reliably retrieve every relevant line item into its prompt context, leading to incomplete calculations or confident mathematical errors. For numerical ledgers, raw transaction databases, and multi-tab financial models, relying on text-based RAG leads to inaccurate conclusions. Tabular records require structured extraction or purpose-built analytical tooling rather than narrative document ingestion. ## How to Convert Unsupported Files for NotebookLM When your working materials include formats that NotebookLM rejects natively, such as Microsoft Excel workbooks, large code repositories, or complex slide archives, practical conversion workarounds can bridge the operational gap. Preparing files properly before import saves hours of manual troubleshooting, prevents corrupted citations, and keeps research workflows moving smoothly forward. The primary objective of pre-processing is to transform complex hierarchical data structures, binary spreadsheets, and multi-file code trees into clean, linear text that retrieval models can ingest without losing essential context. By standardizing formatting, removing binary baggage, and verifying readability, you guarantee that every uploaded source contributes directly to accurate grounded answers rather than triggering unexpected import rejections. ### Converting Excel Workbooks and Tabular Data Because Microsoft Excel files (.xlsx) cannot be uploaded directly through the file picker, teams use three primary methods to prepare spreadsheet data: 1. **Export as CSV with Header Repetition:** For compact datasets that fit within token thresholds, export individual workbook tabs as clean CSV files. Remove blank rows, merged cells, and complex macros before exporting. If your table contains numerous rows, consider adding a text summary column that restates key attributes on each line. 2. **Import into Google Sheets:** Upload your Excel workbook to Google Drive and open it as a native Google Sheet. This enables the direct Google Drive import option in NotebookLM, subject to Google Sheets token limits. 3. **Generate Markdown Summary Tables:** Rather than uploading raw transaction registers, run a local script or spreadsheet formula to produce aggregated Markdown tables. A concise Markdown summary presenting monthly totals by region preserves semantic clarity while fitting easily within NotebookLM token constraints. ### Packaging Codebases and Multi-File Repositories Software engineering teams often want to ground NotebookLM on application code, API specifications, and architectural documentation. NotebookLM does not support folder uploads, zip archives, or direct Git repository connections. To ingest code into NotebookLM, developers use automated bundling scripts: * **Concatenate Key Source Files:** Use command-line tools like `cat` or custom Python scripts to merge related code files into a single structured Markdown (.md) or plain text (.txt) document. * **Prepend File Boundary Headers:** Ensure each concatenated file begins with a distinct Markdown header indicating its relative path (for example, `## File: src/controllers/auth.py`). This gives the retrieval model explicit navigational context when citing code snippets. * **Exclude Build Artifacts:** Strip out compiled binaries, `node_modules`, lockfiles, and minified bundles before concatenation to keep total word counts well below the 500,000-word limit. ### Preparing Scanned PDFs and Media Files Handling complex visual and printed documents requires deliberate pre-processing: * **Optical Character Recognition (OCR):** For scanned legal documents, historical archives, or paper invoices, run an OCR tool before uploading to generate a clean, selectable text layer. This ensures NotebookLM indexes verified text rather than guessing from low-resolution bitmaps. * **Strip PDF Encryption:** If a PDF is protected by permissions or passwords, open the file in a PDF utility and print to an unencrypted PDF copy. * **Split Oversized Slide Decks:** Google Slides sources are capped at 100 slides per file. For comprehensive presentation decks that exceed this limit, divide the presentation into smaller thematic sections before importing. ## Managing Large Document Corpora With Intelligent Workspaces While NotebookLM provides a quick interface for personal note-taking and targeted document synthesis, its architectural boundaries become restrictive for team-wide knowledge management. Organizations managing thousands of client files, multi-gigabyte media assets, and structured spreadsheets require an infrastructure built for persistent storage, automated indexing, and multi-agent coordination. Fastio leaves every vendor's own upload limit exactly where it is; what it adds is a searchable place for the files that do not fit. Rather than manually converting, splitting, and uploading files into isolated notebooks, teams store their complete corpus in an [intelligent workspace](/product/workspaces/). In an intelligent workspace, files are indexed automatically upon arrival, enabling comprehensive search and AI reasoning across projects. ### Hybrid Search and Persistent File Indexing In NotebookLM, files must be manually gathered, imported, and curated within each notebook. When new documents arrive, team members must remember to add them to every relevant project space. In an intelligent workspace, files are indexed automatically upon arrival. Intelligence Mode provides hybrid Search, combining full-text keyword matching, semantic vector retrieval, and search-by-metadata-value across all stored assets. While Google NotebookLM caps each uploaded source file at 200MB, an intelligent workspace accommodates massive file collections with generous multi-gigabyte upload thresholds across Starter, Business, and Enterprise plans. Workspaces connect to existing cloud storage environments. Cloud Sync ships for Google Drive, Dropbox, Box, and OneDrive (one-way or two-way, on a schedule or on demand, never continuous, live, or real-time; SharePoint libraries through the OneDrive connector). Files imported into workspace storage maintain complete per-file version history and a detailed activity log, allowing teams to verify exactly who updated a document and when. ### Structured Data Extraction via Metadata Views To overcome the inherent limitations of language models handling tabular records and document fields, teams use [Metadata Views](/product/document-data-extraction/). Metadata Views turn unstructured workspace documents into live, queryable databases. Instead of writing custom parsing code or rigid OCR templates, users describe the target fields in natural language. AI designs a typed schema (such as Text, Integer, Decimal, Boolean, URL, JSON, and Date & Time), scans matching documents across the workspace, and populates a sortable, filterable spreadsheet. This structured extraction layer works across PDFs, images, Word documents, spreadsheets, presentations, and scanned pages. A legal team can extract contract counterparties and expiration dates, while a finance team can extract invoice line items and totals directly into structured columns without losing relational integrity. ### Connecting External AI Agents via Model Context Protocol NotebookLM is closed to external applications and developer tools. It operates exclusively through Google's web interface, offering no programmatic API for autonomous agents, IDE assistants, or custom workflows. Teams building automated pipelines need [storage for agents](/storage-for-agents/) that connects directly to foundation models. Fastio exposes its intelligent workspaces through the Model Context Protocol (MCP) over Streamable HTTP, allowing any modern AI agent to search, read, and organize workspace files. Agents connect using the appropriate endpoint for their runtime: * **Claude Apps and General Clients:** Connect with OAuth at `https://mcp.fast.io/mcp/tools` (covering claude.ai, Claude Desktop, Claude mobile, and Claude Cowork). * **ChatGPT and Codex:** Install the Fastio plugin from the ChatGPT plugin directory, or configure a custom MCP connection at `https://mcp.fast.io/mcp/operations`. * **Coding Agents:** Point Claude Code, Cursor, Cline, or Gemini CLI to `https://mcp.fast.io/mcp/code`. Setup instructions for human developers are documented at `https://mcp.fast.io/docs`. Through these endpoints, an autonomous agent queries workspace documents using targeted search actions, retrieving verified paragraphs and citations without stuffing entire document collections into local context windows. Check the [pricing](/pricing/) options to choose an appropriate storage tier. ## Best Practices for Organizing NotebookLM Sources To maintain reliable research accuracy and avoid hitting system boundaries in NotebookLM, teams must follow structured operational best practices when preparing, curating, and updating sources. Establishing disciplined ingestion habits guarantees that your grounded notebook remains an authoritative research asset rather than an unmanageable, noisy document repository. Research projects inevitably evolve over weeks and months, accumulating draft revisions, meeting transcripts, slide presentations, and external references. Without active maintenance, source collections become cluttered with conflicting facts, degrading the relevance of generated summaries and increasing the likelihood of hallucinated answers. Curating sources proactively preserves slot capacity and keeps retrieval precision high across complex research initiatives. ### Source Curation and Slot Optimization Because free accounts are capped at 50 sources, careful curation preserves capacity for critical reference materials: * **Consolidate Small Meeting Notes:** Rather than uploading twenty separate two-page memos, merge related project notes into a single chronological digest document. A single Google Doc containing ten weekly updates consumes only one source slot while preserving complete searchability. * **Prune Superseded Documents:** When an updated project brief or contract draft arrives, remove the outdated version from your notebook. Keeping multiple versions of the same document causes NotebookLM to retrieve conflicting instructions, leading to mixed and inaccurate citations. * **Use Source Checkboxes Strategically:** In the Sources panel, uncheck files that are irrelevant to your immediate task. If you are drafting an executive summary on product requirements, unchecking financial ledgers and technical logs focuses the model's attention and reduces retrieval noise. ### Grounding Maintenance and Verification Always verify model answers against primary citations, especially when working with converted files, complex tables, or audio transcripts: * **Inspect Citation Pills:** NotebookLM includes clickable citation pills in its responses. Click these markers to view the exact source text the model referenced. If the cited passage appears garbled or comes from a split table chunk, verify the original file before acting on the information. * **Trigger Manual Refreshes on Drive Edits:** If you make significant revisions to a connected Google Doc or Google Slide, open the source in NotebookLM and click the manual sync icon. Do not assume background polling has updated the index immediately. * **Decouple Quick Synthesis From Production Storage:** Use NotebookLM for rapid exploratory synthesis, ideation, and Audio Overviews. When work transitions to production collaboration, client delivery, or multi-agent execution, store authoritative assets in versioned, shared workspaces. ## Frequently asked questions ### Can NotebookLM read Excel or CSV files? NotebookLM supports CSV files and token-limited Google Sheets, but it does not support direct uploads of Microsoft Excel (.xlsx) files. To use Excel data, you must convert the workbook to a CSV file, save it as a Google Sheet in Google Drive, or export it as a PDF before uploading. NotebookLM treats spreadsheet rows as sequential text, so formula calculations and complex mathematical aggregations cannot be executed reliably. ### What audio file types does NotebookLM accept? Google NotebookLM accepts audio files uploaded as sources across standard containers including MP3, WAV, M4A, AAC, OGG, OPUS, AMR, and AIFF, up to 200MB per file. Upon upload, Google automatically transcribes the audio into text and uses the transcript as the source document. Audio files must contain clear human speech; recordings containing only music, silence, or heavy background noise will fail during import. ### Can I upload Word documents directly to NotebookLM? Yes, NotebookLM supports modern Microsoft Word (.docx) files up to 200MB or 500,000 words per file. You can upload them from your computer or select them from Google Drive. Older binary Word documents (.doc) are not supported and must be converted to .docx or exported as a PDF before uploading. ### What are the file size and word limits per source in NotebookLM? Each source document in NotebookLM can contain up to 500,000 words or 200MB for uploaded files. There is no strict page limit, provided the document remains within the file size and word count boundaries. Free accounts can add up to 50 sources per notebook, while higher paid tiers offer expanded source capacities. ### Why did my YouTube video import fail in NotebookLM? YouTube video imports fail if the video is private or unlisted, if closed captions and transcripts are disabled, or if the video does not contain audible speech. Videos uploaded within the past 72 hours also frequently fail because automated caption tracks have not finished propagating across Google servers. ### How does NotebookLM handle password-protected or scanned PDFs? NotebookLM rejects password-protected and encrypted PDF files immediately upon upload. For scanned PDFs containing only page images, NotebookLM attempts text recognition, but complex layouts or low-resolution scans often produce missing or degraded text. Removing password locks and running optical character recognition before uploading ensures reliable search and retrieval. ### Can NotebookLM ingest entire codebases or GitHub repositories? NotebookLM does not support directory uploads, zip archives, or direct Git repository connections. To analyze code, developers must bundle source files into a single text or Markdown document with clear path headings. For software teams requiring persistent multi-file search across entire repositories, an intelligent workspace connected through the Model Context Protocol provides a scalable alternative. ## Sources - [Google: Gemini Notebook Help](https://support.google.com/gemininotebook/answer/16215270?hl=en): Google NotebookLM caps each uploaded source document at 500,000 words or 200MB for uploaded files, and free accounts can include up to 50 sources per notebook. - [Google: Gemini Notebook Help](https://support.google.com/gemininotebook/answer/16215270?hl=en): Audio files uploaded as sources to NotebookLM are transcribed into text at the time of import and saved as a new source. ## About Fast.io Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.