How to Export Public YouTube Comments With Python, yt-dlp, and a Proxy

Export a reviewed sample of public YouTube comments to CSV with Python while comparing the official API, yt-dlp, proxy configuration, and privacy limits.

Written by the Mexela Editorial Team. Technical guides are reviewed by the Mexela Technical Team under the Mexela Editorial Policy.

Red and white Python terminal beside public video comment rows and a proxy server

PROXY PLANS

Ready to buy proxies for this workflow?

Use the guide below to choose the right proxy type, then start with private proxies for dedicated IPv4 access or shared proxies when price matters more.

For a supported public YouTube comment export, prefer the official YouTube Data API when it provides the fields and volume you need. If a reviewed project uses yt-dlp for public metadata, configure it to skip media, cap the comment sample, route through a proxy only when the network requirement is legitimate, and normalize the result into a minimal CSV. Do not collect private data, deleted material, or more comments than the stated analysis requires.

Comments look like simple rows, but threads, replies, pinned status, edited text, unavailable authors, and changing moderation state complicate the dataset. Before writing Python, decide whether the unit is a top-level comment, a reply, a thread summary, or a daily aggregate.

Evaluate the official commentThreads API first

The official commentThreads.list documentation defines supported fields, pagination, quota behavior, and resource structure. It is usually the cleanest route for an authorized analytics tool because IDs, snippets, and reply counts arrive as structured JSON. Read the API Services terms and store the minimum necessary fields.

An API key or OAuth credential belongs in a secret manager or environment variable. Restrict it, rotate it if exposed, and never publish it in tutorial output. If comments are disabled or unavailable, record that state rather than retrying through many endpoints.

Use yt-dlp only for a bounded public-metadata workflow

yt-dlp can expose public metadata and comments for supported sites, but extractor behavior changes as platforms change. Pin and record the version, read the project’s official documentation, and test one owned or approved public video. This guide does not download video or audio.

from yt_dlp import YoutubeDL
options = {
    "skip_download": True,
    "getcomments": True,
    "quiet": True,
    "proxy": os.environ.get("PROXY_URL"),
    "extractor_args": {
        "youtube": {"max_comments": ["200"]}
    },
}
with YoutubeDL(options) as ydl:
    info = ydl.extract_info(VIDEO_URL, download=False)
comments = info.get("comments") or []

A full proxy URL in an environment variable may expose special-character encoding mistakes. Where possible, generate it at runtime from separately protected fields, redact it from exceptions, and verify the route with a harmless request before starting the export.

Normalize comments without inventing identity

A minimal row can contain video ID, comment ID, parent ID, text, published time, like count when visible, and capture time. Author display names and channel references are personal data in some contexts and may not be necessary for sentiment or topic analysis. Exclude them unless the reviewed purpose requires them.

Preserve line breaks in a JSON source record or encode them correctly for CSV. Spreadsheet-formula injection is a real export risk: cells beginning with `=`, `+`, `-`, or `@` should be handled according to the target spreadsheet policy. Do not strip content in a way that changes sentiment without documenting the transformation.

Write a defensive CSV export

import csv
from datetime import datetime, timezone
with open("youtube_comments.csv", "w", newline="", encoding="utf-8") as fh:
    writer = csv.DictWriter(fh, fieldnames=[
        "video_id", "comment_id", "parent_id", "text",
        "published_at", "captured_at"
    ])
    writer.writeheader()
    for item in comments:
        writer.writerow({
            "video_id": info.get("id"),
            "comment_id": item.get("id"),
            "parent_id": item.get("parent"),
            "text": item.get("text") or "",
            "published_at": item.get("timestamp"),
            "captured_at": datetime.now(timezone.utc).isoformat(),
        })

Validate row counts and unique comment IDs after writing. A successful process with zero rows may mean comments are disabled, the extractor changed, consent interrupted the request, or the chosen sample filter excluded everything. Report the state explicitly.

Handle threads, replies, and pagination honestly

Top-level comments and replies answer different questions. A sample of popular top-level comments should not be described as all audience reaction. Store the sampling rule, maximum rows, sort order, and whether replies were included. If pagination stops early, mark the export partial.

Comment counts can change between page metadata and export time because moderation and deletion continue. Treat the capture as a timestamped snapshot. Do not attempt to recover removed comments or access non-public discussion.

Prepare text for analysis without destroying evidence

Keep an immutable raw text field in protected storage and create separate normalized fields for analysis. Lowercasing, URL removal, emoji conversion, language detection, and deduplication can all change meaning. Version the transformation pipeline and test it on multilingual comments rather than assuming English punctuation.

Aggregate whenever possible. A report about recurring support topics usually needs counts and example themes, not a permanent database of commenter identities. Set a deletion date for raw exports and limit access to the analysts who need them.

Turn observations into a decision-ready report

A useful public YouTube comment export report begins with method and coverage, not a dramatic chart. State which public surface was observed, the countries and languages included, the capture window, the fields supported, and the percentage of planned checks that completed successfully. Then separate the observed facts from the analyst’s interpretation and proposed action. Readers should be able to disagree with an interpretation without doubting where the underlying observation came from.

Include a short limitations box beside the result, not hidden at the end. Note personalization, unsupported markets, missing snapshots, classification uncertainty, and changes in the public interface. Compare findings with primary company or platform sources before turning them into a factual claim. Review the YouTube API Services Terms and YouTube Data API documentation when defining collection and retention rules, because current platform requirements take precedence over assumptions in any tutorial.

Finish with one proportionate next step: repeat a small sample, ask a market specialist to review a cultural interpretation, update an owned landing page, test an original video topic, or investigate an anomalous public price. Do not let the availability of automation expand the project’s scope. The purpose of the pipeline is to support a decision with transparent evidence, not to maximize rows, requests, screenshots, or stored personal information.

A repeatable workflow is more valuable than a lucky result

Start every public YouTube comment export run with a written test matrix. Record the target, country, language, device profile, account state, time, and expected output before opening the first page. Keep one direct control run and change only one variable at a time. This sounds slower than improvising, but it prevents the most expensive mistake in regional research: attributing a difference to the proxy when cookies, localization, personalization, inventory, or timing actually caused it.

Pin the yt-dlp version or API schema, document the sample limit and reply policy, and test the export against a known approved video. Save video ID, method, tool version, sampling rule, row count, unique-ID count, capture time, and an error category with a timestamp and a run identifier. A second operator should be able to repeat the same small test without asking which browser profile, proxy endpoint, or query you used. The proxy verification guide explains how to confirm the exit route before interpreting platform results.

Separate proxy failures from platform and parser failures

A timeout does not automatically mean the proxy is bad, and an empty selector does not prove the platform returned no data. Classify failures at the DNS, TCP, proxy authentication, TLS, HTTP, rendering, consent, and parsing layers. Test the same endpoint with a neutral page, then test the platform manually in the same session. If the page renders but the extractor returns nothing, inspect the markup before rotating addresses or increasing retries.

Separate disabled comments, empty sample, API quota, extractor change, consent interruption, proxy error, and CSV validation failure. Log status codes, elapsed time, final URL, and the name of the failed step, but never log proxy passwords, cookies, authorization headers, or personal account data. Consult the proxy troubleshooting guide and the authentication guide before treating repeated authentication errors as a platform block.

Choose the proxy around the session, not the platform name

Use a stable endpoint only when the reviewed network requirement calls for it, and keep the same route for the bounded export. A stable regional QA session often benefits from a consistent address, while independent public-result checks may tolerate rotation between complete sessions. Rotation in the middle of a cookie-bound flow can create contradictory evidence. Define when an address may change, how many retries are acceptable, and when the run must stop for review.

Use the location guide to choose a market, the static-versus-rotating comparison to design session behavior, and the Mexela Proxy Checker to record the observed exit address. Current inventory belongs on the proxy pricing page, not in a tutorial that will outlive today’s stock.

Responsible use and platform boundaries

Collect only supported public comments for a documented purpose, minimize identifiers, protect raw text, and delete it on schedule. A proxy changes the network route; it does not create permission, remove contractual limits, or make private information public. Prefer official APIs and export tools when they satisfy the goal. For browser-based public checks, use small samples, conservative pacing, caching, and a stop condition when the platform signals that requests should slow down.

Document what you collected, why it was necessary, how long it will be retained, and who can access it. Avoid personal data unless a lawful and reviewed purpose requires it. The responsible web-data guide provides a broader framework for public-data projects.

Frequently asked questions

Is the YouTube Data API better than yt-dlp for comments?

For many authorized projects, yes. The official API offers documented resources and quotas. yt-dlp may suit a bounded public-metadata workflow but requires extractor maintenance and careful terms review.

Does this tutorial download YouTube videos?

No. `skip_download` is enabled and the workflow handles only supported public metadata and comments.

Why did the export return zero comments?

Comments may be disabled, unavailable, filtered by the sample limit, interrupted by consent, or affected by an extractor change. Record the exact state before retrying.

Should I store commenter names?

Only if the reviewed purpose genuinely requires them. Many topic and sentiment analyses can exclude identifiers and retain only minimal comment text and timestamps.

Can a proxy recover deleted or private comments?

No. A proxy changes the network route. It does not grant access to private, removed, or otherwise unavailable material.

Bottom line: prefer the official API, keep yt-dlp exports bounded and versioned, and design the CSV around privacy, provenance, and honest sampling.