For a large video, use the YouTube Data API’s videos.insert method with uploadType=resumable: create an upload session, save its URI, and transfer the media to that URI. If the connection drops, query the session and continue from the byte YouTube confirms it received.
This is an API workflow for developers, not the usual YouTube Studio upload screen. Resumable transfer helps a client recover from interruptions; it does not remove API quota, account restrictions or file-size limits.
When a resumable upload is useful
A resumable session is useful when a video takes a long time to send, or when the connection is unreliable enough that restarting a transfer from zero would be costly. It lets your client keep track of a server-side upload session and recover acknowledged progress after a connection failure. Google for Developers describes the protocol as a way to upload videos more reliably.
This is not a special route around YouTube’s normal requirements. Your API project still needs appropriate authorisation, your account and project remain subject to YouTube’s policies, and the method has documented limits. A session URI is temporary, not a permanent location for the file.
Use the protocol when you are building an application, automation or internal tool that sends a local video file through the Data API. If you are simply uploading one video by hand, Studio is a different workflow and this guide is not a substitute for its instructions. For a screen recording specifically, the practical choices around preparing and sharing the file are covered in how to share a screen recording directly to YouTube.
Before starting, have the final media file available, know its byte length and MIME type, and prepare the video metadata you want to submit. Your client should be able to preserve the session URI and know which part of the local file corresponds to each byte offset. Those details are what make recovery possible rather than a blind retry.
What the API workflow covers
The videos.insert endpoint accepts metadata and media. In a resumable upload, these are handled in stages: the first authenticated request creates a session and supplies the metadata; the API responds with a Location header containing the session URI; subsequent media requests send the binary data to that URI. A completed upload returns HTTP 201 and the created video resource.
The endpoint URL follows this form:
https://www.googleapis.com/upload/youtube/v3/videos?uploadType=resumable&part=snippet,status
Choose the part value for the resource fields your request sets. The example names snippet and status only to illustrate the syntax; set parts that match the metadata in your own request and the fields you need returned. The API documentation explains the videos.insert method, including accepted media types and the method’s current constraints.
The initial request is not the video transfer itself. It establishes the upload and tells the API what to expect. The session URI returned by the server is therefore operational state: keep it until the upload completes or you determine the session has expired. Treat it as sensitive, since a client that possesses it can make requests against that upload session.
A useful design is to keep upload state together: session URI, file identity, total length, media type, and any progress information your application displays. Persist only what your software needs, and ensure a resumed job refers to the same file version. If the source file changes after you open a session, the old offsets no longer describe the new file.
Start a resumable session
Send an authenticated POST to the upload endpoint with uploadType=resumable and the chosen part parameter. Include the video resource as a JSON body. The request also needs headers describing the media that will follow: X-Upload-Content-Length for the total number of bytes and X-Upload-Content-Type for the media MIME type. Set the JSON content type for the metadata body and include the authorisation credentials required for the API call.
Conceptually, the request has this shape:
POST /upload/youtube/v3/videos?uploadType=resumable&part=snippet,status HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Length: TOTAL_LENGTH
X-Upload-Content-Type: video/mp4
{"snippet":{"title":"Example upload"},"status":{"privacyStatus":"private"}}
The values are illustrative, not a complete application. Obtain and refresh credentials using the appropriate Google authorisation flow, use the actual file length, and describe the file with its real media type. Do not copy a sample privacy value without deciding how the video should be published and checking whether your project is permitted to set the intended visibility.
When the initiation succeeds, read the response’s Location header and save its URI. Do not reconstruct it from the endpoint, assume it remains valid indefinitely, or discard it after the first media request. The protocol guide recommends beginning the transfer soon after receiving the URI and resuming promptly after an interruption. See Google’s resumable upload protocol guide for the request and response sequence.
For a robust client, make session creation its own explicit state transition. If the POST fails before a Location header arrives, you have no known session URI to resume against. Handle that as a session-initiation error rather than pretending the media transfer is in progress. Once you have the URI, record it before sending media so a process restart does not erase the only path to recovery.
Transfer the video data
For a single transfer, send a PUT request to the saved session URI with the binary file as the body. Include the media content type and the matching content length. If the request completes successfully, the response indicates completion and returns the created video resource. Your client should check the status code and parse the response rather than treating any closed connection as proof that the upload succeeded.
Chunking is optional. Google says it is rarely necessary and discourages it in general because each additional request has performance implications. A single media request is simpler and avoids chunk bookkeeping, but it provides fewer intermediate progress updates. Resumable sessions can still help recover from a failed transfer; you do not need to split every file into many pieces to use the protocol.
Chunked requests can be useful when you want to show progress or when a client benefits from sending smaller portions over an unstable connection. Each request sends one contiguous range of the file. Except for the final chunk, chunk sizes must be multiples of 256 KB, and the size should stay consistent across requests. Larger chunks mean fewer requests and can be more efficient on a reliable connection; smaller chunks make each individual retry smaller but add request overhead. There is no universally best chunk size.
| Approach | Request pattern | Progress visibility | Practical trade-off |
|---|---|---|---|
| One media transfer | One PUT for the file |
Limited during transfer | Less request overhead; recovery still relies on querying session status after a failure |
| Chunked transfer | A sequence of PUT requests for byte ranges |
Easier to report confirmed progress between requests | More requests and bookkeeping; smaller portions can reduce the amount resent after a failure |
For chunked requests, send the range and total length in Content-Range, and keep the body’s byte count consistent with that range. For instance, a request representing bytes 0 through N of a file with total length TOTAL_LENGTH identifies that exact inclusive range. Avoid calculating the next range from the number of bytes your client attempted to send: the server’s acknowledged range is the authority after an uncertain response.
Check status and recover after interruption
A connection can fail after some bytes arrived but before your client received a response. Do not assume that all bytes in the failed request were rejected, and do not blindly resend that same chunk. Send an empty PUT to the saved session URI with Content-Range: bytes */TOTAL_LENGTH to ask the server about the session’s current state.
If the response is 308 Resume Incomplete, inspect its Range header. That header identifies the last byte successfully received. The next media request must begin at the following byte. If the server reports that bytes through N are present, resume at N+1; if no range is reported, follow the protocol’s indication that no media bytes have yet been received. This check prevents overlap or a skipped section when the outcome of a previous request is unknown.
A successful completion may have occurred even if the client lost the final response. Status checking is therefore useful at the end as well as after a mid-transfer interruption. Handle the response body and status according to the API protocol, and keep the resulting video resource or identifier once completion is confirmed.
Google’s guide identifies 500, 502, 503 and 504 as server errors that can be retried for resumable uploads. Use exponential backoff rather than sending requests in a tight loop, and honour Retry-After when the response supplies it. A backoff strategy should have sensible bounds and should surface a failure to the caller if repeated attempts do not recover; retries are not a guarantee that every error is transient.
A 404 from an expired session URI means that session can no longer be used. Start a new resumable session and transfer the file again from the beginning. This is why the session URI should be persisted for recovery but not treated as durable storage. Your application should make the restart visible in its state and avoid reporting the old acknowledged offset as progress on the new session.
Account for API and upload limits
The current videos.insert reference lists a maximum file size of 256 GB and accepts video/* or application/octet-stream. These are API method limits, not a promise that every project or account can upload every file of that size in every circumstance. Check the current method reference and your own project settings before designing around the upper bound.
There is also an API project visibility caveat. Google’s method reference warns that videos uploaded through videos.insert by unverified API projects created after 28 July 2020 are restricted to private viewing until each project passes an audit. Do not promise that an API upload will immediately be public based only on metadata you send. Check the project’s verification status and the current official guidance before building a publication workflow around public visibility.
Quota is particularly important for automation that retries or uploads repeatedly. As listed on Google for Developers’ videos.insert page in September 2026, the method is described with 100 calls per day in the Video Uploads quota bucket. The YouTube Data API overview, as listed in September 2026, gives default allocations of 100 videos.insert calls and 100 search.list calls, alongside 10,000 units per day for other endpoints. Google’s revision history records a move to separate granular buckets for videos.insert and search.list beginning on 1 June 2026.
These figures describe documentation and default allocations, not a universal quota promise for every project or a permanent rule. Check the current quota shown for your Google Cloud project in the Cloud Console, and consult the live YouTube Data API overview and revision history before relying on a particular allocation. Also account for the fact that an upload attempt, a retry, and other endpoint calls may affect the available quota according to the applicable current bucket rules.
For a channel built around pre-recorded material, API file upload and continuous broadcasting are separate jobs. A workflow that merely gets a file into YouTube does not keep a live broadcast running. If you are preparing a programme loop, the editorial and playback decisions in when to use a playlist for pre-recorded live streaming and how to show a holding screen between playlist videos address a different stage from this transfer protocol.
Decide whether your client library should handle it
The protocol is documented for developers who need to implement the HTTP flow, but you do not necessarily need to write that flow yourself. Google’s YouTube Data API documentation and client library examples demonstrate resumable media uploads with retry handling. If a library supports the required upload method for your language and version, using it can take care of request construction, chunk state and some retry mechanics.
Check what the library actually does before assuming it handles every recovery case. Confirm how it exposes progress, how it stores or restores session state, what errors it retries, and whether it lets your application inspect the final API response. A convenient upload abstraction does not remove the need to manage credentials, API errors, quotas, file metadata or project restrictions.
Manual HTTP handling makes sense when you need precise control over requests, are working in an environment without a suitable library, or need to integrate upload state with a custom job system. It also means you own the correctness details: preserving the URI, constructing exact byte ranges, querying status after uncertain outcomes, observing backoff guidance, and restarting when a session expires. Test those cases deliberately, including the case where the server accepts bytes but the client loses the response.
For a service that turns an already uploaded video into an always-on broadcast, rather than implementing an API file-transfer client, StreamNeo removes the need to keep your own computer on for that separate streaming task: you upload the file once, provide your YouTube stream key, and the cloud broadcast runs with monitoring and automatic restart if it drops. It is YouTube-only, and the upload protocol described above remains a distinct API workflow.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does resumable upload mean I have to send chunks?
No. A resumable session can carry the file in one media transfer, and chunking is optional. Use chunks when progress reporting or smaller retry units are useful enough to justify additional requests and implementation state.
How do I know where to resume?
Send an empty PUT to the saved session URI with Content-Range: bytes */TOTAL_LENGTH. On 308 Resume Incomplete, use the Range response header to find the last byte YouTube received, then begin at the following byte.
What if the session URI returns 404?
The session has expired and cannot be resumed. Initiate a new session and upload the file from the start; do not carry progress from the old session into the new one.
Can an API upload be made public immediately?
Not necessarily. Google warns that uploads from certain unverified API projects are restricted to private viewing until the project passes an audit. Check the current videos.insert guidance and your project’s verification status before depending on public visibility.