I Ripped a Creator's Entire Cross-Platform Archive in One Morning

There’s a creator I’ve been studying for a few months. Same format every time: hold up a phone, read a real text-thread from a workplace horror story, react to it, drop a lesson. It works. The comment sections are stacked. The videos cross-post to LinkedIn, TikTok, Instagram, Facebook, and YouTube Shorts.

I wanted the whole catalog on my hard drive so I could study the format instead of the algorithm’s daily whim. This morning I got it — every platform, no logins, one script per surface.

Here’s what actually worked, what didn’t, and why.

LinkedIn is the easiest one, and nobody knows it

If you had asked me last week which platform would be hardest to rip video from, I would have said LinkedIn. It’s a walled-garden professional network. There’s no public download API. The mobile app buries the share sheet.

Turns out yt-dlp handles it with no cookies at all:

yt-dlp "https://www.linkedin.com/feed/update/urn:li:activity:<activity-id>"

That’s it. You get a clean 720×1280 h264 file, no watermark, no login prompt. LinkedIn native video is basically a public CDN with a share URL wrapped around it.

The catch is discovery, not download. A profile’s Videos tab only surfaces about 20 recent posts, and there’s no paginated archive endpoint. If you want more than that, you have to fish activity URNs out of the DOM as you scroll — or accept the 20-most-recent as your working set and update it weekly.

TikTok gives you everything, quietly

TikTok is the opposite. Discovery is trivial (their profile page loads every video ID into a virtual scroller) and downloads are wide open:

yt-dlp \
  --download-archive archive.txt \
  -o "%(id)s - %(title).60s.%(ext)s" \
  "https://www.tiktok.com/@creator_handle"

You get 1080×1920 hevc, no watermark, and TikTok doesn’t care. That single command pulled 135 videos in about eleven minutes. The --download-archive flag is the important part — re-running the same command tomorrow only grabs whatever is new, because yt-dlp writes each downloaded video ID to archive.txt and skips them on the next pass.

That turns a one-time rip into a passive monitor. Cron it weekly and you have a permanent local mirror of any creator’s TikTok output, updating itself.

YouTube fought back

YouTube is where things got interesting.

The first 100 shorts came down fine. Somewhere around video 101, my IP got soft-banned. Every subsequent request came back with a bot-detection page instead of a video stream. Seventeen videos in the target format still missing, and no way to grab them from this box without waiting hours for the block to decay.

Two ways out:

# Option A: use your browser's cookies (Google account risk)
yt-dlp --cookies-from-browser chrome "<url>"

# Option B: wait it out, or route through a different IP

I noted the 17 missing video IDs in a missing17.txt file and moved on. If you’re doing this at scale, --cookies-from-browser chrome is the escape hatch, but it puts your actual Google account on the hook if YouTube decides to escalate. I don’t feed that to a background cron.

Facebook is the weird one

Facebook is a split personality. If you have a direct video URL, yt-dlp will happily pull a 1080×1920 file with no cookies. But if you point it at a Page and expect enumeration, it hits a login wall. There is no anonymous “list all videos on this page” endpoint the way TikTok has.

So Facebook only works if you already know each URL. That’s a scrape-then-rip pipeline, not a single command, and I skipped it. The same creator had 90+% of the same content on TikTok anyway.

The final layout

Everything went into one directory keyed by platform:

~/Videos/creator-archive/
├── linkedin/          20 files
│   └── archive.txt
├── tiktok/            135 files
│   └── archive.txt
└── youtube/           40 files (+ misc in youtube/other/)
    ├── archive.txt
    └── missing17.txt

Each subfolder has its own archive.txt, so re-running any of the four commands next month only pulls the deltas. No dedup logic. No database. Just a text file per platform holding the IDs I’ve already seen.

What this is actually for

I’m not building a piracy tool. The creator posts publicly on every platform I ripped from, and I’m not redistributing anything.

I’m doing it because studying format at scale requires having the content locally. You cannot skim 135 videos on TikTok’s UI — every tap re-triggers the algorithm and pulls you into a new rabbit hole. You cannot A/B compare the LinkedIn cut vs the TikTok cut of the same video when they live on two different apps that don’t talk to each other. You cannot feed a video to a local model for shot-by-shot analysis if it’s stuck behind a share URL.

Once the archive exists, the interesting work starts:

• Same video, different platforms. Compare the LinkedIn cut and the TikTok cut of the same reaction. Which one keeps the intro? Which one adds captions? Where do they trim?
• Format decomposition. Feed a batch through ffprobe for durations, then a vision model for shot lists. Find the format’s median hook length, average cut cadence, common overlay positions.
• Cross-platform presence mapping. Which videos exist on all five platforms and which are exclusives? Exclusives are signal — the creator decided that surface was worth a bespoke asset.

None of this is possible with the “save to bookmarks” workflow. You need the files.

The takeaway

Every platform has a policy against automated downloading, and every platform has a yt-dlp extractor. The gap between those two facts is where a lot of interesting content research lives — competitive analysis, format study, archiving journalism that might get deleted, saving your own posts from a platform you no longer trust.

Four things I’d hand a friend who wanted to do the same:

1. Use pipx install yt-dlp, not your distro’s package. The stock version is always months behind extractor changes.
2. --download-archive turns any rip into an incremental sync. One-time job becomes a weekly cron with no rewrite.
3. Discovery and download are two different problems. TikTok solves both. LinkedIn only solves download. Facebook only solves download. YouTube solves both until it doesn’t.
4. Don’t feed your real Google cookies to a background job. If you need --cookies-from-browser chrome for YouTube at scale, spin up a burner account first.

The archive is 4.3 GB. The whole thing took a morning. Now the real work starts — which is figuring out what makes the format actually land, one shot at a time.