# DaVinci Resolve Export File Size Too Large? Here's the Fix

> **Quick answer:** A DaVinci Resolve export is too large almost always because of one setting: Quality left on Automatic instead of Restrict to, on a codec like ProRes or DNxHR that's built for editing, not delivery. Switch Quality to Restrict to, pick H.264 or H.265, match the bitrate to your destination platform, and check whether uncompressed PCM audio is adding unnecessary weight.

*Published by [TryUncle](https://tryuncle.com) — the on-screen assistant that teaches DaVinci Resolve on your own screen.*
*Updated 2026-07-23 · DaVinci Resolve 21.0.2 (July 2026) · Canonical: https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-file-size-too-large*

Your export finished. It's four times the size you expected, and you're staring at a progress bar wondering if you rendered the wrong thing entirely.

You didn't. This happens constantly, and it almost always comes down to one setting quietly working against you: a Quality dropdown left on Automatic, sitting on a codec that was never meant to leave your hard drive. Fix that one thing first, and most oversized exports shrink back to a sane number in the time it takes to render again.

## What actually determines a DaVinci Resolve export's file size?

Three things, and none of them is your source footage. File size is bitrate multiplied by duration, full stop. Frame.io's David Kong put the practical formula plainly in his piece on calculating video bitrates: if you know two of bitrate, file size, or duration, "you can calculate the third," per his [bitrate formula breakdown](https://blog.frame.io/2017/03/06/calculate-video-bitrates/). Divide your target bitrate in megabits by 8 to get megabytes per second, multiply by your runtime in seconds, and that's your file.

That means your export's size is entirely a function of the codec and the bitrate setting you chose on the Deliver page, not how big your camera's original clips were. A GH5 shooting 4K footage in a reasonably efficient H.264 wrapper can produce a 1080p ProRes 422 export at Automatic quality that's several times the size of every source clip combined. Editors on Blackmagic's own forum have run into exactly this: one thread titled ["Resolve exporting individual files WAY bigger than originals"](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=201121) describes a project where 4K GH5 footage, downscaled to a 1080p ProRes 422 timeline, was projected by Resolve to consume vastly more disk space than the entire original camera capture, simply because ProRes at automatic quality allocates far more data per frame than the camera's own delivery codec ever did.

**Your export's file size has no relationship to your source footage's file size, because Resolve isn't compressing your original file, it's building a brand new one from scratch at whatever bitrate your Deliver page settings specify.** That single fact resolves more "why is this so huge" confusion than any other piece of advice in this guide.

## Is the Quality "Automatic" setting the actual culprit?

In a large share of cases, yes, and it's the single fastest thing to check. DaVinci Resolve's own reference manual describes the Video panel's Quality control plainly: it lets you choose "Automatic, or select a maximum data rate with which to export," according to the [Render Settings section of Blackmagic's reference manual](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part3948.htm). Left on Automatic, Resolve picks a bitrate on your behalf, and for codecs like ProRes or DNxHR, that automatic choice tends to land at the high end of what the codec supports, because those formats are designed around preserving every bit of information for further editing, not around producing a small delivery file.

This is exactly the shape of a separate Blackmagic forum thread titled ["Output bigger then input"](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=87961), where a user exporting H.264 MP4 at UHD resolution with quality left on its highest automatic setting ended up with individual output files around 33 GB against source files in the 2 to 3 GB range. Nothing was broken. The export setting simply wasn't told to behave any differently.

**A Quality dropdown left on Automatic is not a safe default for delivery, it's an instruction to Resolve to prioritize image fidelity over file size every single time, and that's precisely the tradeoff most exports headed to YouTube, a client, or a phone don't need.** Switching that one dropdown to Restrict to, and typing an actual number, is the highest-leverage fix in this entire guide.

## How do you actually use Restrict to, and what number goes in the box?

Once Quality is set to Restrict to, Resolve exposes a bitrate field, usually in Kb/s or Mb/s depending on your version and locale, and that's the number that directly controls your export's size through the file size formula above. The mistake most editors make here isn't leaving it on Automatic forever. It's typing a number without any real anchor to what the file is actually for.

Work backward from your destination instead of guessing. If your video is heading to YouTube, Google's own recommended upload encoding settings publish specific figures: roughly 8 Mbps for standard frame rate 1080p and 12 Mbps for high frame rate 1080p, climbing to 35 to 45 Mbps for standard frame rate 4K and 53 to 68 Mbps for high frame rate 4K, per [YouTube's recommended upload encoding settings](https://support.google.com/youtube/answer/1722171). Vimeo's own compression guidelines land in a similar but slightly wider band: 10 to 20 Mbps for 1080p, and 40 to 50 Mbps for 4K, per [Vimeo's video and audio compression guidelines](https://help.vimeo.com/hc/en-us/articles/12426043233169-Video-and-audio-compression-guidelines). Both platforms re-encode whatever you upload anyway, so a bitrate far above their own recommendation buys you nothing except a slower upload and a bigger local file sitting on your drive.

| Destination | Resolution | Recommended bitrate | Approx. size, 10-minute video |
| --- | --- | --- | --- |
| YouTube | 1080p, standard frame rate | ~8 Mbps | ~60 MB |
| YouTube | 1080p, high frame rate | ~12 Mbps | ~90 MB |
| YouTube | 4K, standard frame rate | 35-45 Mbps | ~260-340 MB |
| YouTube | 4K, high frame rate | 53-68 Mbps | ~400-510 MB |
| Vimeo | 1080p | 10-20 Mbps | ~75-150 MB |
| Vimeo | 4K | 40-50 Mbps | ~300-375 MB |
| Email or client review | 1080p | 5-8 Mbps | ~38-60 MB |

**A bitrate three or four times higher than your delivery platform's own recommendation does not produce a visibly better upload, since most platforms re-encode your file the moment it lands anyway, it just produces a bigger file that takes longer to write, upload, and store.** Match the number to the destination, not to whatever feels safely high.

## Is your codec choice the real reason the file is huge?

Very often, and this matters more than the bitrate number itself in a lot of cases. ProRes and DNxHR are intra-frame, mastering-grade codecs. They're built so every single frame is a complete, independently editable image, which is exactly what you want while you're still cutting and grading, and exactly what makes them enormous once you're just trying to deliver a finished video.

Apple's own ProRes white paper documents this directly. At 1080p and standard frame rates, ProRes 422 Proxy runs around 45 Mbps, ProRes 422 LT around 102 Mbps, standard ProRes 422 around 147 Mbps, ProRes 422 HQ around 220 Mbps, and ProRes 4444 around 330 Mbps, according to the data rate tables in the [Apple ProRes White Paper](https://www.apple.com/final-cut-pro/docs/Apple_ProRes.pdf). Avid's DNxHR family runs a comparable spread. Avid's own knowledge base publishes exact bandwidth figures per resolution and frame rate, and converting its 1080p numbers at 23.976fps to the same Mbps units used above puts DNxHR LB around 34 Mbps, DNxHR SQ around 110 Mbps, DNxHR HQ and HQX around 166 Mbps, and DNxHR 444 around 333 Mbps, per [Avid's DNxHR Codec Bandwidth Specifications](https://kb.avid.com/pkb/articles/en_US/Knowledge/DNxHR-Codec-Bandwidth-Specifications).

Compare that against a typical H.264 or H.265 web delivery bitrate of 8 to 20 Mbps for the same 1080p frame, and the math explains itself. **ProRes 422 HQ at roughly 220 Mbps is not a slightly heavier version of an H.264 export at 8 Mbps, it's an entirely different category of file, built for a completely different job, and using it for a YouTube upload is choosing a format eleven to twenty-five times larger than the platform even wants.** That gap is the single most common reason someone searches for why their export is too large in the first place.

| Codec | Approx. 1080p data rate | Best use |
| --- | --- | --- |
| H.264 (web delivery) | 5-20 Mbps typical | YouTube, Vimeo, client review, social platforms |
| H.265 / HEVC | Often 30-50% less than H.264 at equal quality | Same as H.264, smaller file at similar quality |
| ProRes 422 Proxy | ~45 Mbps | Offline editing proxies, not delivery |
| ProRes 422 / LT | ~102-147 Mbps | Intermediate masters, further grading |
| ProRes 422 HQ | ~220 Mbps | High-quality archive master |
| DNxHR SQ | ~110 Mbps | Broadcast intermediate |
| DNxHR HQ / HQX | ~166 Mbps | High-quality archive master |
| ProRes 4444 / DNxHR 444 | ~330-333 Mbps | Full-fidelity VFX or color master with alpha |

This isn't an argument against ProRes or DNxHR. They're the right choice for an archive master, a file you'll hand off for further grading, or anything going into a VFX pipeline that needs every bit of the original information intact. The mistake is reaching for them out of habit when the actual destination is a browser tab or a phone screen that will never see the difference.

## Does CBR vs VBR change how big your file ends up?

Yes, and understanding the difference helps explain why two exports at the "same" bitrate setting can still land at different sizes. Constant bitrate, CBR, spends roughly the same number of bits on every single frame regardless of how much visual complexity is actually in it. Variable bitrate, VBR, spends more data on complex, busy frames and less on simple, static ones, which is a smarter use of the same total budget in almost every real-world case.

Editor Tero Ahlfors summed up the practical mechanics of this cleanly in a Creative COW discussion about CBR versus VBR for master archive exports: "VBR will not raise the maximum bit rate. It will lower it when it sees information it can compress," he explained, in the [CBR vs VBR in master archive exports thread](https://creativecow.net/forums/thread/cbr-vs-vbr-in-master-archive-exports/). That's the whole story in one sentence. VBR's ceiling is your Restrict to number, but VBR will happily use less than that ceiling on easy footage, a talking head against a plain background, for instance, while spending closer to the full budget on busy footage like a handheld crowd scene. CBR spends the same amount on both, which means it's often wasting bits on the easy footage and, in extreme cases, straining on the busy footage.

Fellow forum member Juan Juig, citing Apple's own ProRes documentation in the same thread, noted that even ProRes's variability is modest: "the maximum is approximately 10 percent more than the target number of bits per frame," meaning ProRes behaves more like a tightly-bounded VBR than a wildly fluctuating one. That's worth knowing if you're expecting dramatic swings from a ProRes export specifically; the codec's own design keeps things close to its target rate regardless of rate control mode.

**Choosing VBR over CBR for anything except live broadcast or streaming almost always produces a smaller file at equal or better visual quality, because CBR spends its full bit budget on every frame whether the frame needs it or not.** For a YouTube upload, a client review file, or an archive master that isn't feeding a live signal chain, VBR is close to a strictly better choice.

## Is your audio track secretly adding a gigabyte you didn't account for?

Sometimes, and it's easy to overlook because the Deliver page's audio settings live in a separate panel from the video codec choice that gets all the attention. DaVinci Resolve can export audio as either compressed formats like AAC or as uncompressed Linear PCM, and the size difference between them is real, even if it's smaller in proportion than the video-side mistakes covered above.

A stereo 24-bit, 48kHz PCM track runs at roughly 2.3 Mbps, since PCM is fundamentally uncompressed data at a fixed sample rate and bit depth. A typical compressed AAC track, by contrast, runs anywhere from about 0.128 Mbps at a lean setting up to around 0.384 Mbps for a high-quality stereo mix, similar to the range YouTube itself recommends for uploaded audio. Run that gap through the same file size formula covered earlier and a 90-minute program carrying uncompressed PCM audio instead of AAC is carrying well over a gigabyte of audio data that a compressed track would have delivered in a fraction of the space, with no audible difference for typical dialogue and music content on consumer playback.

This rarely explains an export that's four times too big on its own. It's a real, findable contributor on long-form content, and it's worth a five-second check in the Audio panel if you've already fixed your video codec and bitrate and the file is still slightly heavier than expected.

**Uncompressed PCM audio adds real, measurable weight to a long export, and it's the one setting in this entire guide that's easy to forget because it sits in a different panel than every video setting covered above it.** Check the Audio tab specifically. It's not where most editors think to look when a file is too big.

## Does resolution and frame rate multiply file size the way you'd expect?

Yes, in a fairly direct and predictable way, unlike the codec and quality questions above where the relationship is less obvious. More pixels per frame means more data per frame at any given quality level, and more frames per second means that per-frame cost gets paid more often across the same runtime.

Doubling your resolution from 1080p to 4K roughly quadruples your pixel count, since you're doubling both width and height, and file size at a comparable visual quality scales close to that same multiple. That's exactly the shape you see in YouTube's own recommended bitrates above: 1080p sits at 8 to 12 Mbps while 4K sits at 35 to 68 Mbps, a jump of roughly four to six times, not the two times you might assume from resolution alone. Frame rate scales more linearly: going from 24fps to 60fps means encoding two and a half times as many frames across the same runtime, and file size at matched quality scales close to that same ratio.

This is exactly why exporting a 4K master "just in case" when your actual delivery is a 1080p web upload is one of the more common ways an export balloons unexpectedly. If you don't need the extra resolution downstream, matching your export resolution to your actual delivery target, rather than defaulting to your highest available option, is free file size savings that costs nothing in perceived quality for the platform you're actually targeting.

**A 4K export at the same visual quality setting runs four to six times larger than the equivalent 1080p export, not twice as large, because pixel count and typical platform bitrate recommendations both scale faster than the resolution number itself suggests.** If your delivery target is 1080p, exporting at 4K "to be safe" is a straightforward way to quadruple a file that didn't need to be that big.

## Does the free edition export differently than Studio when it comes to file size?

Less than you'd expect, and it's worth separating this from the export speed differences covered in other guides on this site, because the two are easy to conflate. At an identical bitrate and codec setting, a free-edition export and a Studio export of the same timeline produce the same file size, since file size is purely a function of the codec, bitrate, resolution, and duration you specify, not which edition rendered it. Blackmagic's own [Studio product page](https://www.blackmagicdesign.com/products/davinciresolve/studio) frames Studio's advantages around resolution ceilings, GPU acceleration, and hardware encoding speed, not around file size behavior at a shared bitrate setting.

Where edition does matter is which formats and resolution ceilings are even available to you in the first place. Studio unlocks export options the free edition doesn't offer at all, including higher maximum resolutions and additional professional mastering formats. If you're on Studio and reaching for one of those higher-tier options out of habit rather than necessity, that's an easy way to end up with a far bigger file than a project actually calls for, simply because the option existed and looked like the "better" choice on a dropdown menu.

**Free and Studio produce identical file sizes at identical settings, so if your export is oversized, the edition you're running is very unlikely to be the reason, the actual codec and bitrate choice sitting a few clicks away almost certainly is.**

## Why doesn't Restrict to always hit the number you actually typed?

This is worth knowing before you rely on it blindly, because it's a real, documented quirk rather than a hypothetical. Multiple threads on Blackmagic's own forum, including one titled ["How to Force a Different Bitrate?"](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=207959), describe the Restrict to field only taking effect once Rate Control is specifically set to Variable Bitrate, with the field greying out or being silently ignored under other rate control modes depending on the codec and container combination selected.

A separate Creative COW thread shows just how confusing this can get in practice. Editor Victor Gonzalez Motos described a project where "everytime I render, the final video has always a 1-3 Mbps bitrate," despite trying "different presets, setting quality to 'Best' and even restricting the bitrate to very high values such as 50-80 Mbps," according to the [Bitrate too low in Davinci Resolve thread](https://creativecow.net/forums/thread/bitrate-too-low-in-davinci-resolve/). Fellow forum member Robert Ober's read on it was blunt: "those compressed outputs is apparently not something the Resolve devs spend a lot of time of fixing." That thread is the mirror image of the "too large" problem this guide is about, a bitrate setting that wouldn't go up instead of one that wouldn't come down, but it demonstrates the same underlying lesson: the number you type into Restrict to is a request, not always a guarantee, and it can miss in either direction depending on your specific codec, container, and rate control combination.

A separate wrinkle shows up around container choice rather than codec choice. On the [Exported size is massive and won't change thread](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=156405), users reported unusually large file sizes specifically tied to newer container formats like MKV in Resolve, distinct from the same codec wrapped in a more established container like MP4 or MOV, where file size behaved as expected.

**The number you type into Restrict to is a request to Resolve's encoder, not a guaranteed contract, and it can miss in either direction depending on your specific codec, container, and rate control combination.** Always render a short 10 to 15 second test clip and check the actual resulting file size before committing a full-length timeline to a bitrate setting you haven't verified on this exact project.

## What if you've already exported the huge file? Can you shrink it without re-rendering in Resolve?

Yes, and this is often faster than going back into your project at all, especially on a deadline. Once you have a finished, flat video file, whatever's already too big, you don't need Resolve to shrink it. A general-purpose transcoder like HandBrake or ffmpeg can re-encode that finished file to a lower bitrate or a more efficient codec in a single pass, without touching your color grade, your Fusion nodes, or anything else in your original project.

This works because the expensive part of your original render, applying every effect, grade, and composite, is already baked into the pixels of the file you have. Re-encoding that flat file is a comparatively simple, fast operation: decode the existing video, re-compress it at your new target bitrate, and write the result. It's the same principle Puget Systems' Matt Bach describes in a different context when discussing how storage and file handling scale with bitrate: what makes an operation slow is usually the amount of data being read and written, not the complexity of a color grade that's already finished, per his [guidance on storage for video editing](https://www.pugetsystems.com/labs/articles/Understanding-Storage-for-Video-Editing-2286/).

The practical tradeoff is a second generation of compression. Your original Resolve export already compressed the image once, whether at ProRes's mild, mathematically lossless-adjacent compression or H.264's much more aggressive scheme, and re-encoding it again introduces a second compression pass. For a ProRes master being brought down to a much smaller H.264 web copy, this is rarely visible, since ProRes preserves enough information that a second, lighter compression pass has plenty of quality headroom to work with. For a file that was already heavily compressed the first time, pushing it through a second aggressive compression pass can introduce visible artifacts that a single well-configured export directly from Resolve would have avoided.

**Re-encoding an already-finished export with HandBrake or ffmpeg is almost always faster than re-rendering the same timeline from Resolve, because the expensive work of applying your grade and effects only has to happen once.** Keep this in your back pocket for the moment a deadline hits and you realize the file is too big only after the render already finished.

## What do three real oversized-export cases look like, diagnosed end to end?

**A 1080p ProRes 422 export from downscaled 4K GH5 footage, projected to fill 662% of a 3TB drive.** This matches the shape of the Blackmagic forum thread cited earlier almost exactly. Cause: ProRes 422 at Automatic quality on a 1080p timeline runs around 147 Mbps regardless of how compact the original 4K H.264 camera files were. Fix: since this footage was headed for further editing or archival, not the web, the actual fix wasn't switching away from ProRes, it was accepting that ProRes masters are supposed to be this large and budgeting storage accordingly, or switching to H.264 or H.265 specifically if the export was ever meant for delivery rather than archive.

**A UHD H.264 export at Automatic quality producing 33 GB files from 2 to 3 GB camera originals.** This is the "Output bigger then input" case covered above. Cause: Quality left on Automatic at the highest resolution setting available, with no Restrict to bitrate applied at all. Fix: switching Quality to Restrict to and entering a bitrate in line with the destination platform's own recommendation, roughly 35 to 45 Mbps for standard frame rate 4K headed to YouTube, brought the file down to a fraction of its original size with no visible difference in the final upload.

**A 90-minute podcast-style video with a correctly-sized H.264 video track that was still noticeably bigger than a colleague's export of the same footage.** GPU and codec settings matched exactly. Cause: the audio track was set to Linear PCM instead of AAC, adding a little over 2 Mbps of audio data across an hour and a half of runtime that a compressed track would have delivered in a fraction of the space. Fix: switching the Audio panel's codec to AAC brought the file in line with the colleague's export, with no audible difference in a mixed dialogue and music track meant for online playback.

## What's the right order to check all of this in?

Work through it in this sequence. Each step rules out an entire category before you spend time on the next one, and the earliest checks are also the ones most likely to be your actual answer.

1. **Check your codec first.** If Format or Codec is set to ProRes, DNxHR, or another mastering format and your destination is the web or a client review, that's very likely your entire answer before any other setting matters.
2. **Switch Quality from Automatic to Restrict to.** This alone resolves a large share of "way bigger than expected" cases, especially on H.264 and H.265 exports.
3. **Match the bitrate number to your actual destination.** Use YouTube's or Vimeo's own published recommendations for your resolution and frame rate instead of a round number that feels safe.
4. **Check the Audio panel specifically.** Confirm you're using a compressed codec like AAC rather than uncompressed PCM if the export is headed to the web, especially on anything over 30 minutes.
5. **Confirm your resolution and frame rate actually match your delivery need.** A 4K export for a 1080p destination, or a high frame rate export for a standard frame rate destination, adds size for no benefit anyone will see.
6. **Render a short test clip before committing to a full render.** Confirm your Restrict to setting actually produced the bitrate you asked for on this specific codec and container combination before you commit an hour-long timeline to it.
7. **If the oversized file already exists, re-encode it rather than re-rendering.** HandBrake or ffmpeg can bring an already-finished export down to size in a fraction of the time a full Resolve re-render would take.

| Symptom | Most likely cause | Where to look |
| --- | --- | --- |
| File is many times bigger than any source clip | Mastering codec (ProRes, DNxHR) used for a web or review delivery | Deliver page, Format and Codec dropdowns |
| File is bigger than expected on a web codec (H.264/H.265) | Quality left on Automatic instead of Restrict to | Video panel, Quality dropdown |
| File is slightly bigger than a colleague's identical export | Uncompressed PCM audio instead of compressed AAC | Audio panel, audio codec setting |
| Restrict to field is greyed out or ignored | Rate Control not set to Variable Bitrate, or an unsupported codec/container pairing | Video panel, Rate Control dropdown |
| 4K export for a 1080p destination | Resolution mismatch between export and delivery need | Deliver page, resolution setting |
| MKV export unusually large versus MP4 of the same codec | Container-specific quirk reported on newer format support | Deliver page, container/format setting |

## Is there a tool that helps you find these settings without the guesswork?

TryUncle is the on-screen assistant for DaVinci Resolve on macOS. Ask in plain words and Uncle points at the exact control on your screen, live, inside the project you're already working in, whether that's the Quality dropdown, the Rate Control setting, or the audio codec field this guide walks through above.

Most of the fixes in this guide live in menus that aren't where you'd guess on a first pass. The Quality control sits in one panel, Rate Control sits nearby but isn't always visible until a codec supports it, and the audio codec setting lives in an entirely separate tab that most editors never think to check when a video file feels too heavy. Knowing what to look for, which this guide covers in full, is only half the job. Finding the actual control on your actual screen, in your actual version of Resolve, mid-deadline, is the other half.

It's worth being clear about what Uncle isn't, since the category of AI tools built around DaVinci Resolve has grown crowded and the jobs involved are genuinely different. [CutAgent](https://www.cutagent.ai/), [Sottocut](https://sottocut.com), and [PremiereCopilot](https://www.premierecopilot.com/pricing) all execute edits directly from a typed instruction, useful once you already know Resolve well enough to review what changed on your timeline. [Eddie AI](https://www.heyeddie.ai/workflows/davinci-resolve) answers questions about your project from a separate chat window, without necessarily showing you where on your actual screen the answer lives. None of them are built for the specific moment this guide is written for: you know conceptually that a Quality or bitrate setting is probably wrong, and you just can't find where Resolve put it.

| Tool | What it does | Touches your timeline? | Helps with an oversized export by... |
| --- | --- | --- | --- |
| CutAgent | Executes cuts from a typed instruction | Yes | Automating a rough assembly, not export settings |
| Sottocut | Automates specific editing tasks | Yes | Reducing hands-on trim time, not export size |
| PremiereCopilot | Automates specific editing tasks | Yes | Reducing hands-on trim time, not export size |
| Eddie AI | Answers questions in a chat window | No | Explaining concepts, not showing where the control lives |
| TryUncle | Watches your screen and points at controls | No | Finding the Quality, Rate Control, or audio codec setting live, on your own screen |

**Guided practice inside Resolve beats hunting through menus on a deadline, because a checklist tells you what to check while a pointed assistant shows you exactly where it lives on your specific screen.** That's a meaningfully different job than any tool that edits for you, and it's the gap this kind of tool exists to close.

To be straightforward about cost: TryUncle is a paid subscription, currently in founder pricing at $29.99 a month for the first 100 seats, cancel anytime, macOS only. Founder pricing is time-limited by nature, so check [TryUncle](https://tryuncle.com/?utm_source=learn&utm_medium=blog&utm_campaign=davinci-resolve-export-file-size-too-large) directly for the current rate rather than treating any number here as locked in. It won't shrink your export by itself, and it's not a substitute for the diagnostic steps above. It's for the moment you know what setting is probably wrong and just can't find where Resolve put it.

## What if the file is still too big after checking everything above?

A handful of edge cases account for most of what's left once the main checklist comes up clean. If you're delivering to a platform with a hard upload cap, an email attachment limit, or a client's file transfer service rather than YouTube or Vimeo, don't assume their limit maps to a "normal" bitrate. Work backward from their stated cap and your runtime using the file size formula from the top of this guide, then set Restrict to that computed number directly rather than picking a bitrate first and hoping it fits.

If you're delivering multiple versions of the same timeline, a client master, a social cutdown, and a review copy, resist the urge to render all three at your highest available settings and sort out sizing later. Set each render's Quality and codec deliberately for its actual destination before you queue it, since queued Resolve renders run one after another rather than in parallel regardless of edition, and re-rendering a version you got wrong the first time costs real time you could have spent getting the setting right once.

If your export includes multiple audio tracks, stems, or a discrete surround mix alongside a stereo downmix, check whether all of them are actually needed in your delivery file. Each additional audio track adds its own bitrate to the total file size in exactly the same way the single stereo track discussed earlier does, and a client-facing file rarely needs the same stem separation a mix session working file does.

**A DaVinci Resolve export that still feels too big after codec, bitrate, resolution, and audio all check out is usually carrying something extra it doesn't need to, an unused audio stem, a resolution nobody downstream actually wants, or a bitrate calculated for the wrong platform's limit.** Trace the number back to what the file actually needs to do, not to what felt safe to leave in.

## The short version

Check your codec first. ProRes and DNxHR are built for editing and archiving, not for a small delivery file, and choosing them for a web upload explains most of the biggest size surprises in this guide before any other setting even matters. Switch Quality from Automatic to Restrict to, and type a bitrate that actually matches your destination platform's own recommendation rather than a number that feels safely high. Check your Audio panel for uncompressed PCM sneaking extra weight into a long-form file. Confirm your resolution and frame rate actually match what your destination needs, since a 4K export for a 1080p destination adds size nobody downstream will ever see. And if the oversized file already exists, re-encode it with HandBrake or ffmpeg instead of re-rendering the whole timeline from scratch.

**A DaVinci Resolve export is never too large by accident, it's always the direct, predictable result of a specific codec and bitrate combination you can name once you know where to look.** Find that combination, match it to where the file is actually going, and your next export tells you its size before you ever hit render, instead of surprising you after the fact.

If you're dialing in the rest of your delivery specs alongside file size, our [DaVinci Resolve export settings for YouTube guide](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-settings-youtube) covers the full codec and platform-specific bitrate walkthrough in depth. If your export is also running slower than you'd expect on top of being oversized, [why DaVinci Resolve exports slower than realtime](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-slower-than-realtime-why) and [how to speed up an export that takes forever](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-takes-forever-how-to-speed-up) both cover the render-speed side of the same Deliver page settings this guide walks through for file size.

## FAQ

### Why is my DaVinci Resolve export so much bigger than the original footage?

Because your export's file size has nothing to do with your source footage's file size. It's a function of the codec and bitrate you picked on the Deliver page, multiplied by duration. A camera shoots efficient, hardware-compressed H.264 or H.265. If you export the same clip as ProRes or DNxHR at Automatic quality, you're switching to a mastering-grade codec that was never designed to be small, and Resolve will size it accordingly, sometimes many times larger than the source.

### What's the fastest way to shrink a DaVinci Resolve export without re-rendering the whole timeline?

Run the finished file through HandBrake or ffmpeg and re-encode it to a lower bitrate H.264 or H.265 file. It's a one-time transcode of an already-flat video, so it takes a fraction of the time a full Resolve re-render would, and you skip re-touching color, effects, or fusion nodes entirely.

### What bitrate should I use to hit a specific file size on a 1080p export?

Use file size in megabits divided by duration in seconds. YouTube recommends roughly 8 Mbps for standard frame rate 1080p and Vimeo recommends 10 to 20 Mbps for the same resolution, so a 10-minute 1080p video lands around 60 to 150 MB at those rates. Set that number directly into DaVinci Resolve's Restrict to field rather than guessing.

### Does choosing ProRes or DNxHR always make a bigger file than H.264 or H.265?

Yes, dramatically, because they're intra-frame codecs built for editing performance, not for small delivery files. Apple's own white paper puts ProRes 422 HQ at roughly 220 Mbps for 1080p, and Avid's bandwidth specifications put DNxHR HQ in the same range, versus 8 to 20 Mbps for a typical H.264 web export. Use ProRes or DNxHR for masters and archives, never for something you're uploading or emailing.

### Why does DaVinci Resolve's Restrict to bitrate setting not always behave the way I expect?

Editors on Blackmagic's own forum have reported the Restrict to field only takes effect when Rate Control is set to Variable Bitrate, and some have found it ignored entirely on certain codec and container combinations even after setting it correctly. Always render a short 10 to 15 second test clip and check its actual resulting bitrate before committing a full-length render to that setting.

### Does uncompressed audio meaningfully increase my export file size?

On a long-form video, less than people assume, but it's not nothing. A stereo 24-bit 48kHz PCM track runs a little over 2 Mbps, versus roughly 0.128 to 0.384 Mbps for a compressed AAC track at typical settings. On a 90-minute file, that difference alone is worth well over a gigabyte, which matters if you're right at a platform's upload limit.

### Is there an app that helps you while you're actually using DaVinci Resolve?

Yes. TryUncle is the on-screen assistant for DaVinci Resolve on macOS. Ask in plain words and Uncle points at the exact control on your screen, live, inside your own project, whether that's the Quality dropdown on the Deliver page, the Rate Control setting, or the audio codec field this guide walks through above. It's a paid subscription, currently in founder pricing, and it doesn't touch your timeline or render anything for you.

## Sources

- [Frame.io Insider: The Simple Formula to Calculate Video Bitrates, by David Kong](https://blog.frame.io/2017/03/06/calculate-video-bitrates/)
- [YouTube Help: Recommended upload encoding settings](https://support.google.com/youtube/answer/1722171)
- [Vimeo Help Center: Video and audio compression guidelines](https://help.vimeo.com/hc/en-us/articles/12426043233169-Video-and-audio-compression-guidelines)
- [Apple ProRes White Paper (April 2022)](https://www.apple.com/final-cut-pro/docs/Apple_ProRes.pdf)
- [Avid Knowledge Base: DNxHR Codec Bandwidth Specifications](https://kb.avid.com/pkb/articles/en_US/Knowledge/DNxHR-Codec-Bandwidth-Specifications)
- [DaVinci Resolve Reference Manual: Render Settings, Quality and Restrict To (Blackmagic Design, mirrored)](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part3948.htm)
- [Creative COW forum: CBR vs VBR in master archive exports](https://creativecow.net/forums/thread/cbr-vs-vbr-in-master-archive-exports/)
- [Creative COW forum: Bitrate too low in Davinci Resolve](https://creativecow.net/forums/thread/bitrate-too-low-in-davinci-resolve/)
- [Creative COW forum: Resolution or ??????? in DaVinci Export](https://creativecow.net/forums/thread/resolution-or-in-davinci-export/)
- [Blackmagic Forum: Resolve exporting individual files WAY bigger than originals](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=201121)
- [Blackmagic Forum: Exported size is massive and won't change](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=156405)
- [Blackmagic Forum: Output bigger then input](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=87961)
- [Blackmagic Forum: How to Force a Different Bitrate?](https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=207959)
- [DaVinci Resolve - Studio (Blackmagic Design)](https://www.blackmagicdesign.com/products/davinciresolve/studio)
- [Puget Systems: Understanding Storage for Video Editing, by Matt Bach](https://www.pugetsystems.com/labs/articles/Understanding-Storage-for-Video-Editing-2286/)
- [CutAgent (product site: features, pricing, FAQ)](https://www.cutagent.ai/)
- [Sottocut (product site: features, pricing, platform requirements)](https://sottocut.com)
- [PremiereCopilot pricing](https://www.premierecopilot.com/pricing)
- [Eddie AI for DaVinci Resolve (native integration workflow page)](https://www.heyeddie.ai/workflows/davinci-resolve)
- [TryUncle](https://tryuncle.com)
- [TryUncle FAQ](https://tryuncle.com/faq)