공용 자체 File types 페이지가 허용하는 영상 형식은 딱 셋이다 — .webm, .ogv, .mpg/.mpeg. MP4와 MOV는 H.264·H.265의 사용에 “로열티 지불이 요구될 수 있”어서 빠져 있다. 일반 업로드 양식은 100MB에서 멈추고, 5GiB는 업로드 마법사의 청크 업로드로만 닿으며, 크롬이 123에서 Theora 디코딩을 제거한 지금 허용 목록에서 실제로 재생되는 건 WebM뿐이다. 출처가 확인된 규정들, 브라우저 안에서만 도는 WebM 변환, 그리고 공용 자체 안내서의 VP9 + Opus 경로가 더 나은 경우까지 정직하게 정리했다.
구글 자체 도움말은 비즈니스 프로필 영상을 숫자 세 개로 못 박는다 — 최대 30초, 최대 75MB, 720p 이상 — 그리고 프로필 사진에는 10KB~5MB의 JPG/PNG 창을 따로 준다. 지도에서 내 가게에 영상을 올리는 손님에게도 같은 30초 천장이 걸린다. 출처가 확인된 규정들, 무손실 컷이 그 천장보다 몇 초 짧게 노려야 하는 이유, 그리고 비즈니스 사진까지 같은 워크스루에서 정확한 프레임으로 뽑아내는 법 — 전부 내 기기 위에서 — 을 정리했다.
애플 자체 사양표는 앱 미리보기를 단단히 묶는다: 15~30초, .mov/.m4v/.mp4, H.264 또는 ProRes 422(HQ), 최대 30fps와 500MB, 기기별 지정 해상도. 구글 플레이는 파일을 아예 받지 않는다 — 공개 또는 일부공개에 광고 없는 유튜브 URL 하나, 자동 재생은 처음 30초뿐. 출처가 확인된 규정들, 앱 화면 캡처가 재인코딩의 상처를 가장 크게 입는 영상인 이유, 그리고 무손실 컷을 애플의 단단한 천장 너머로 밀어낼 수 있는 키프레임 디테일까지 정리했다.
줌 자체 페이지 기준으로 무료 플랜은 내 데스크톱의 MP4로 로컬 녹화한다 — 클라우드 트리머는 유료에, 원본을 덮어쓰는 파괴적 방식이고, 12시간당 5회로 제한된다. 팀즈는 주최자 OneDrive에 MP4를 저장하는데 마이크로소프트는 그 무게를 시간당 400MB로 잡고 기본값으로 120일 뒤 만료시킨다. 미트는 유료 Workspace 에디션에서만 녹화된다. 출처가 확인된 사실들, 그리고 내 기기 위의 무손실 트림이 내부 논의 한 시간을 누군가에게 정말 필요한 클립 하나로 바꾸는 과정 — 녹화가 내 컴퓨터를 떠나는 일 없이 — 을 정리했다.
엣시는 자체 고객센터 기준 상품 영상을 15초로 제한하고 오디오를 지워버린다 — 용량은 100MB로 넉넉하게 주면서다. 이베이는 1분 이하를, 그것도 콕 집어 H.264로 요구하고 업로드마다 검토를 거친다. 쇼피파이는 10분·1GB를 호스팅하고 WebM까지 받는다. 출처가 확인된 숫자들, 그래도 용량이 무는 단 하나의 경우(분당 약 400MB인 4K/60), 그리고 내 기기 위의 무손실 트림이 셋 모두에 맞는 첫수인 이유를 정리했다.
노션 무료 플랜은 자체 고객센터 기준 업로드하는 모든 파일을 5MB로 제한한다 — 그리고 지원 포맷 목록의 영상 형식은 WebM이 아니라 MP4다. 트렐로 무료 보드는 Atlassian 문서 기준 첨부당 10MB, 아사나는 모든 플랜에서 파일당 100MB다. 출처가 확인된 숫자들, NearVid의 실제 프리셋 기준으로 각 예산에 대략 몇 초가 들어가는지, 그리고 데모를 트렐로 카드 커버에서 바로 재생시키는 너비 300px 미만 GIF 요령을 정리했다.
왓츠앱의 일반 미디어 경로는 영상을 480p로 재인코딩한다 — 9to5Mac 보도 기준 HD 옵션으로도 720p에, 그마저 여전히 압축이다. 같은 파일을 문서로 첨부하면 왓츠앱 자체 발표 기준 압축 없이 최대 2GB까지 보낼 수 있다. 각 경로가 실제로 하는 일, 문서 전송에 붙는 코덱 함정, 그리고 NearVid의 무손실 트림이 원본 화질 경로를 실용적으로 만드는 법을 정리했다.
2026년 8월 13일 디스코드가 무료 업로드 상한을 10MB에서 20MB로 올렸다 — 예전 25MB보다는 여전히 낮고, Nitro 티어는 50MB·500MB 그대로다. 출처가 확인된 숫자들, NearVid의 실제 품질 프리셋 기준으로 20MB에 WebM·MP4가 대략 몇 초나 들어가는지, 그리고 게임 클립을 내 기기 안에서 상한 아래로 맞추는 무손실 트림 우선 워크플로를 정리했다.
링크드인 자체 고객센터는 네이티브 영상을 5GB, 15분으로 제한한다 — 하지만 둘 다 통과하는 영상도 0%에서 멈추는 경우가 많다. 지원되는 .mov·.mp4 컨테이너 자체가 아니라 그 안의 코덱이 진짜 문제이기 때문이다. 링크드인의 실제 업로드 규격, 아이폰·맥 촬영본이 유독 잘 걸리는 HEVC 함정, 그리고 NearVid의 트림과 WebM·MP4 변환으로 업로드 전에 로컬에서 고치는 법을 정리했다.
애플 팟캐스트는 2026년 초 실제 영상 기능을 출시했고 스포티파이도 같은 기술을 도입하는 중이다. 에디슨 리서치에 따르면 주간 청취자는 이제 시청과 청취를 거의 비슷한 비율로 한다. 하지만 애플 자체 RSS 규격이 받아주는 형식은 그대로다 — MP3 아니면 AAC, 영상은 아니다. 영상으로 녹화한 에피소드에서도 오디오를 따로 뽑아내야 하는 이유와, NearVid의 오디오 추출 기능이 어떤 브라우저에서든 로컬로 그 일을 해내는 방법을 정리했다.
X 무료 등급은 자체 고객센터 기준 영상을 140초, 512MB로 제한하며 Premium은 이를 4시간, 16GB까지 끌어올린다. Bluesky는 자체 프로토콜 소스 기준 MP4만 받고 앱은 실제로 약 100MB 선에서 업로드를 막으며, 길이 상한 3분은 2025년 3월부터 적용됐다. 지금 시점의 정확한 숫자와 출처, 그리고 NearVid의 무손실 트림으로 클립 하나를 어느 쪽 제한에도 맞추는 법을 정리했다.
아이폰은 iOS 11부터 기본으로 영상을 HEVC로 녹화해 왔지만 Windows는 여전히 HEVC 디코더를 기본 탑재하지 않는다 — 마이크로소프트 공식 지원 문서는 정확한 "확장 프로그램이 필요합니다" 오류와, PC마다 반복해야 하는 1회 0.99달러짜리 해결책을 그대로 보여준다. 왜 이런 일이 생기는지, 그리고 구매나 업로드 없이 NearVid가 로컬에서 해결하는 법을 정리했다.
2026년 3월 유튜브는 데스크톱 커스텀 썸네일 업로드 제한을 2MB에서 50MB로 25배 늘렸다 — TV에서 더 선명한 썸네일을 위해서다. 하지만 모바일 앱 업로드와 데이터 API의 thumbnails.set 엔드포인트는 여전히 2MB로 제한된다. 유튜브 자체 규격이 무엇을 요구하는지, 무엇이 바뀌었는지, 그리고 NearVid의 원본 해상도 프레임 추출이 어떻게 맞아떨어지는지 정리했다.
슬랙 자체 고객센터는 커스텀 이모지 GIF를 128KB 미만, 50프레임 이하로 제한한다. 평범하게 내보내면 왜 둘 다 넘기기 쉬운지, 그리고 NearVid의 트림·fps·너비 조절값을 올바른 순서로 써서 업로드 실패를 반복하지 않고 그 제한 안에 들어가는 법을 정리했다.
무료 브라우저 화면 녹화 도구가 WebM을 기본값으로 쓰는 건 브라우저 자체의 MediaRecorder API가 가장 잘 지원하는 형식이기 때문이다 — 하지만 caniuse.com에 따르면 아이폰 Safari의 완전한 WebM 재생은 iOS 17.4부터고, 마이크로소프트 공식 파워포인트 문서는 WebM을 Windows에만 올려두면서 오디오 재생엔 별도 코덱 설치까지 요구한다. 정확히 어디서 막히는지, 그리고 NearVid의 Convert to MP4로 로컬에서 해결하는 법을 정리했다.
Gmail, Outlook.com, Yahoo Mail 모두 메일 첨부를 25MB로 제한한다. 지금 시점의 정확한 숫자와 출처, 실제로 안전한 목표가 그보다 살짝 낮아야 하는 이유, 그리고 Quality 선택 옆에 새로 생긴 "≈" 예상 결과 크기 표시가 재인코딩을 기다리기 전에 그 프리셋이 맞는지 알려주는 방법을 정리했다.
OpenAI의 전사 API는 업로드 하나당 25MB로 제한하고, Gemini 앱 무료 등급은 오디오 업로드 길이를 영상의 두 배까지 허용하며, Otter의 자체 문제해결 안내조차 결국 영상을 걷어내라고 말한다. 지금 시점의 정확한 숫자와 출처, 그리고 오디오 트랙만 먼저 뽑아내는 NearVid의 extractAudio() 기능이 그 예산의 대부분을 되찾아 주는 이유를 정리했다.
web.dev 자체 예시: 같은 클립이 GIF로는 3.7MB, MP4로는 551KB, WebM으로는 341KB다. Lighthouse의 "애니메이션 콘텐츠에 영상 포맷 사용" 감사가 실제로 무엇을 확인하는지, 영상을 GIF처럼 동작하게 만드는 마크업, 그리고 NearVid 같은 도구가 소스 클립을 페이지에 쓸 수 있는 파일로 만드는 데 어디까지 도움이 되고 어디부터는 아닌지를 정리했다.
GitHub는 플랜과 무관하게 이미지·GIF를 10MB로 제한하고, Discord 무료 등급은 2024년 10MB로 낮아졌으며, Slack은 파일당 1GB까지 허용하지만 무료 플랜 기록은 90일만 보관한다. 지금 시점의 정확한 숫자와 출처, 같은 분량에서 GIF가 영상보다 훨씬 커지는 이유, 그리고 변환 전에 클립을 먼저 트림하는 것이 어떤 상한이든 아래로 맞추는 가장 큰 요령인 이유를 정리했다.
인스타그램 릴스와 유튜브 쇼츠는 3분, 틱톡 업로드는 10분까지 — 세 플랫폼 모두 상한을 계속 늘려왔다. 지금 시점의 정확한 숫자와 출처, 업로드 전 재인코딩 대신 NearVid의 무손실 트림이 나은 이유, 그리고 다른 업로드 기반 변환 사이트 대신 내 기기에서 직접 트림해야 하는 구체적인 이유(2025년 FBI 경고와 2024년 데이터 유출 사건)를 정리했다.
NearVid의 프레임 추출 기능은 가장 가까운 키프레임이 아니라 정확한 프레임을 뽑아낸다 — 하지만 잘못된 초를 고르면 모션 블러나 어중간한 전환 프레임이 나온다. 탐색이 실제로 어떻게 동작하는지, 무엇이 정지 화면을 나쁘게 만드는지, 그리고 미리보기 없이 타임스탬프를 고르는 법을 정리했다.
WebCodecs 스파이크는 자체 테스트 브라우저에서 H.264를 전혀 찾지 못했지만, VP9+Opus로 demux-decode-encode-mux-재생 파이프라인 자체는 실제로 증명했다. 스파이크가 증명한 것과 증명하지 못한 것, 실제로 만난 버그 두 개, 그리고 프로덕션이 스파이크의 mp4box.js + mp4-muxer 대신 Mediabunny를 선택한 이유까지, 두 단계로 이어지는 실화.