Give it a channel, a playlist or a keyword and get the videos back as rows: the video id and title, a link, the channel and its id, the view count both as YouTube prints it and as a number you can sum, how long ago it went up, the running time, and a thumbnail. Twelve columns, one row per video.
The input box takes four different things, and you can mix them in one list - a channel, a playlist, or just a phrase to search for.
@handle, a channel id, a playlist URL, or a plain keyword. Or upload a CSV, XLSX, TXT or Parquet file.It reads YouTube's own JSON API rather than scraping the page HTML, which is why the fields come back structured rather than parsed out of a layout that changes.
A channel URL, an @handle, a channel id, a playlist link or a bare keyword all go in the same box, and you can mix them in one list. Nothing has to be normalised before you start.
The display text and the underlying number arrive as separate columns, so nothing has to guess what 1.2M means before a total can be computed.
It reads YouTube's own JSON interface rather than parsing rendered HTML. That is why the columns stay stable when the site's layout does not.
This export has real data behind it, so the formats below are measured rather than described. Two of its properties change how you plan a run, and both are worth knowing before the table.
Shorts and regular videos are a choice, not a filter. The video type control is an either/or: a run returns one or the other, never both, and no run we have ever mixed them. It follows that pulling a channel's whole output is two runs rather than one. It also matters for what you get back - every shorts row arrives with no publish date and no running time, because those are not shown on a short. If your analysis needs a date or a duration, you need the regular-videos pass.
The publish date is relative, and nothing in the file anchors it. Every value reads 9 days ago or 3 months ago, and there is no scraped-at column, no timestamp, nothing dated anywhere in the twelve. So the export cannot tell you when a video actually went up - only how old it was when you looked. Record the run date alongside the file, because a week later the same file quietly means something else.
Taken from the header row and the JSON keys of real runs and confirmed against the platform's published column list. The formats are measured from populated cells.
video_type: /watch?v=<id> for a regular video and /shorts/<id> for a short. The id is always in there.UC. The stable way to group by channel - a channel can rename itself, and this will not change. It too can be blank on keyword results.5.6K views. It is not always a view count: a single view reads 1 view, and a live stream reads <n> watching, which is concurrent viewers rather than lifetime plays.4.1M views came back as 4099999. This is the column to sum, sort and compare on; views is for showing a human.9 days ago, 2 weeks ago, 3 months ago. Never an absolute date, and never present on a short. See the note below about anchoring it.m:ss or h:mm:ss. Not present on a short, and not present on a live stream.short or video, matching the Video Type you chose for the run. A run returns one or the other, so this column is constant within a file - it is there to tell two files apart after the fact.frame0.jpg on shorts, and hqdefault, hq720 and custom variants elsewhere - so read the column rather than building the URL yourself. The video id is always in it.Three things will bite if you do not plan for them. First, published is relative and there is no timestamp anywhere in the file - no scraped-at, no run date, nothing. The export tells you a video was 3 months ago as of the moment you ran it, and a file read later says the same words about a different date. Store the run date with the file. Second, views_parsed is the exact number and views is the rounded text, which is the reverse of what the name implies: sum and sort on views_parsed. Third, the same video_id can appear more than once in a run - we checked, and the only column that differs between the copies is query, because two inputs that resolve to the same channel each return the video. De-duplicate on video_id if you want unique videos, or keep the copies if you care which query found what. And one smaller thing: title and channel_title both carry trailing whitespace, so trim before you match on either.
One input list, one limit and one either/or choice. The video type is the one that changes what comes back rather than how much of it - pick it deliberately.
A few examples of how teams use a channel's catalogue to answer a question they actually have.
A handle in, the catalogue out, with view counts you can sum. Two runs - one shorts, one regular - show how a channel splits its effort between formats, which a glance at the front page will not.
Sorting on the parsed view count separates the handful of videos doing the work from the long tail. Because the number is exact rather than the rounded display text, the ordering holds even among videos that all read the same on screen.
A plain phrase in the query box searches YouTube, so a topic becomes a candidate list with channels and view counts attached - a starting point for creator outreach that is not someone's favourites.
No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that you pay as you go, at the same flat rate as every other scraper here.
On every new account, one-time. No credit card. Per-query limits, file upload and every export format included.
About $2 per 1,000 videos. Worth remembering that a channel's shorts and its regular videos are two runs, so a full catalogue costs both. The estimator shows the row count and credit cost before a run starts.
Volume pricing, dedicated workers and an SLA for ongoing monitoring or very large historical pulls. Tell us your numbers and we will put together a quote.
LIVESCRAPER10 at checkout.The natural next step: feed it the video ids from this export and get the spoken content as timed rows. What a channel publishes, and then what it actually says.
For the other half of a topic's visibility. A video's reach on YouTube and the pages ranking for the same phrase are different questions with different answers.
Short answer: this reads public listing metadata through YouTube's own interface, and takes no video content - but YouTube's terms are stricter than most, and that is worth reading properly.
What comes back is the information a channel page shows anyone: titles, view counts, how long ago something went up, running times and thumbnails. No video file is downloaded, nothing behind a sign-in is touched, and no private or members-only content is involved. The scraper reads YouTube's own JSON interface rather than parsing the rendered page.
That said, YouTube's Terms of Service restrict automated access, and unlike a marketplace or a directory this is a platform that says so explicitly and enforces it. Google also publishes an official Data API for much of this. If you are operating at any scale, or building a product on top of the results, the honest position is that the official API is the sanctioned route and this is not - so the decision is yours to make with your own advice, not one this page can make for you.
On personal data: the rows describe videos and channels rather than individuals, and a channel name is a published identity rather than a private one. Even so, a small creator's channel can be a person by any other name, so if you are building anything that profiles individuals rather than measuring content, that is the point at which data-protection duties start applying to you. We run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
500 one-time free rows on every new account - no expiry date. After that $0.002 per row, pay as you go - no card on file until you say so.
Livescraper's YouTube Video Scraper turns a channel, a playlist or a search phrase into a table of videos. You paste your queries one per line - a channel URL, an @handle, a channel id, a playlist link, or a plain keyword - or upload them as a CSV, XLSX, TXT or Parquet file, choose whether you want shorts or regular videos, cap the rows per query, and download the results as a clean CSV, Excel or JSON file. It reads YouTube's own JSON interface rather than parsing rendered HTML.
Each row carries twelve columns: the query it came from, the video id and title, a link, the channel name and its id, the view count both as YouTube prints it and as an exact number, how long ago the video went up, its running time, whether it is a short or a regular video, and a thumbnail link.
Content teams run a rival's handle to see what is actually being published rather than what the front page features. Analysts sort on the exact view count to separate the videos carrying a channel from its long tail. Partnerships teams put a topic in as a keyword and get a candidate list of creators with channels and view counts attached.
Three properties are worth knowing before you build on it. Shorts and regular videos are an either/or choice rather than a filter, so a channel's full output is two runs - and shorts arrive with no publish date and no running time, because a short does not show them. The publish date that regular videos do carry is relative, reading as 9 days ago or 3 months ago, and there is no timestamp column anywhere in the export to anchor it, so record the run date alongside the file. And views_parsed is the exact count while views is the rounded display text, which is the reverse of what the name suggests - sum and sort on the former. Start free: your first 500 rows cost nothing and need no credit card, and after that it is a flat $0.002 per row.