Runner / Fixes
You dragged it in, you got a waveform and a blank video track, and the same file plays perfectly in VLC. Nothing is corrupt. Here is the actual cause and three ways out of it.
Short answer
Your file's video stream is AV1 or VP9. Premiere Pro cannot decode either, so it imports the audio it understands and leaves the video track empty. YouTube serves these instead of H.264 on most higher-resolution downloads, which is why the problem shows up on 4K far more often than on smaller sizes.
Fix it by converting the video stream to H.264, or by downloading in a format that was never AV1 to begin with. Both are below.
Before changing anything, check what you actually have. If you have ffmpeg installed:
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of csv=p=0 "yourfile.mp4"
If that prints av1, you have found your problem. On Windows without
ffmpeg, right-click the file, open Properties › Details, and look at
the video codec line. av01 means the same thing.
A quick sanity check: if the file opens and plays in VLC, Windows Media Player, or Clipchamp but not in Premiere, the file is fine and the decoder is the problem. Re-downloading the same file will not help.
This is the reliable option. It re-encodes the video into a codec Premiere has understood for over a decade.
ffmpeg -i input.webm -c:v libx264 -crf 18 -preset slow \
-pix_fmt yuv420p -c:a aac -b:a 192k output.mp4
What those flags do:
-crf 18 is visually near-lossless. Lower is better quality and a
bigger file; 18 to 20 is the sensible band for editing.-pix_fmt yuv420p matters. Without it you can end up with a file
Premiere still refuses.-c:a aac converts Opus audio, which Premiere is also unreliable
with, into something safe.Expect roughly real-time or slower on a 4K clip. It is a full re-encode, not a rewrap.
Use an intermediate codec instead of H.264, which holds up far better through a grade:
ffmpeg -i input.webm -c:v dnxhd -profile:v dnxhr_hq \
-pix_fmt yuv422p -c:a pcm_s16le output.mov
The files are much larger. That is the trade.
If you are using yt-dlp, you can tell it to prefer H.264 and skip the whole problem:
yt-dlp -S "res,vcodec:h264" -f "bv*+ba[ext=m4a]/b" "URL"
The catch, and it is a real one: H.264 often does not exist above 1080p. On most videos this quietly caps you at 1080p. If you genuinely need 4K, you are converting, and Fix 1 is your answer.
If you hit this once a month, convert by hand and get on with your day. Fix 1 takes two minutes.
If you hit it several times a week, the manual loop of download, inspect, convert, re-import is worth removing. That is the specific job Runner does: it is a panel inside Premiere Pro that fetches the clip, notices the codec Premiere cannot read, converts it to H.264 before you ever see it, and puts the result in a tray you drag onto the timeline. You never learn that AV1 was involved.
Runner is a Premiere Pro panel that converts anything Premiere cannot decode before it reaches your timeline. Free while it is in beta, Windows only.
Download for WindowsNo, and updating will not fix it. Editors have reported the same audio-only import behaviour on current releases, including Premiere 25 and 26. There is a long-running feature request on Adobe's own community forum asking for AV1 support.
Clipchamp and VLC ship their own AV1 decoders. Premiere relies on a different media engine that does not include one. Same file, different decoder, different result.
No. Premiere has to decode the source once to build a proxy, and that is the step that fails. Convert the source instead.
Yes. Premiere handles VP9 inconsistently at best, and a VP9 stream commonly fails outright with unsupported compression type "vp09". It is not limited to 4K: 1080p downloads come back VP9 often enough that checking the codec beats guessing from the resolution. The fix is the same as for AV1.