After Effects Export Pixelated or Blocky? Fixes

Motion graphics should be the cleanest video you ever make. The shapes are perfect, the text is vector, and nothing is shot through a lens. Then you export, open the file, and the lower third is rough. A gradient has stripes. A thin red line crawls. A logo has blocks around it that were not on the screen in After Effects.

Almost every case comes down to a handful of causes, and most are fixed in the render settings or in the second step after the render. I will go through them in the order I would check them, with numbers from my own encoding tests where I have them, and with clear notes about what I have not tested. I cannot run After Effects on my test machine, so the menu advice below is from how the program is documented and commonly used. Menu names change between versions, so treat them as pointers and check your own copy.

First, where does the blockiness appear?

The location tells you the cause.

• Everywhere, including big smooth areas: the bitrate is too low, or the render resolution is too small.
• Around text and thin lines of color: chroma subsampling, covered below.
• In gradients and soft shadows as bands: bit depth and lack of noise.
• On scaled footage or images only: layers enlarged beyond their native size.
• Only in the upload to a site: the platform’s re-encode, not your export.

Check by looking at the rendered file, not the preview in the composition panel. The preview can be set to a lower resolution on purpose, for speed, and it is not what the render uses unless you set it so.

The render resolution trap

In the render settings, resolution can be set to Full, Half, Third or Quarter. It is meant for fast draft renders. If it was left at Half, your output is rendered at half the width and height and then enlarged to fit the composition, which looks soft and blocky. Look at the render queue before you press render: the resolution should be Full and the quality Best for a final.

A related setting is the preview resolution in the composition viewer, which is Auto or Full or Half. It only affects what you see while working. If you judge sharpness from a half-resolution preview, you may be tempted to over-sharpen things that are fine in the render.

Layers scaled beyond their size

A raster image or footage that is scaled to 200 percent in the timeline has been enlarged, and the program has to invent pixels. The result is soft and may show stair steps. Options:

• Use a bigger source image. A 1000 pixel wide picture covering a 1920 pixel wide frame is being stretched 1.9 times.
• For vector artwork, such as Illustrator files, turn on Continuously Rasterize so the program draws it fresh at the output size rather than enlarging a small copy.
• Check the layer quality setting. Best quality uses better sampling than draft, and the sampling method, bilinear or bicubic, matters for scaled layers. Bicubic is the sharper choice for enlarging.
• For footage, consider upscaling it with a purpose-built step before it goes into the composition, such as the Lanczos filter described in how to make low quality video HD. In my scaling test, Lanczos scored 33.58 dB against 33.38 for bicubic and 31.53 for nearest neighbor. The gap between good and poor scaling was larger than the gap between the two good ones.

A simpler rule: make the composition the size you will deliver and prepare your assets at or above that size.

Nested compositions and effects order

When you nest one composition inside another and scale it, the inner composition is rendered at its own size and then scaled, unless the layer is set to collapse transformations. A small inner composition scaled up will look soft. Make the inner composition the size you need, or collapse transformations so the program renders at the final scale.

Effects like blur, glow and sharpen are also resolution dependent. A blur of 20 pixels at 1080p becomes half as strong at 4K, so a project that was tuned at a small size can look different when you change the size. That is not blocking, but it explains some of the mismatches between a preview and a final.

The big one: how the file is encoded

If the composition looks clean at 100 percent zoom and the exported file does not, the encoding step is the cause. Compression is lossy, and the bitrate sets how much is thrown away.

My bitrate test on a 1080p clip shows the shape of it. The same clip encoded at 0.5, 1, 2, 4, 8 and 16 Mbps scored 28.5, 31.3, 34.7, 38.7, 42.7 and 45.7 dB. Every doubling of bitrate bought roughly 3 to 4 dB. If your export is a low-bitrate preset, blocks are guaranteed. The bitrate guide gives starting values for common sizes.

Motion graphics are tricky for compression in two ways. Flat areas and sharp edges are easy, so the file looks fine at first and then breaks at the edges of text. And fine detail like thin lines, small text and noise-free gradients show every flaw, because there is no texture to hide it. Give graphic work at least the bitrate you would give live footage of the same size.

Which route to use

Recent versions of After Effects route H.264 output through Adobe Media Encoder, and older ones had it in the Output Module. Depending on what you have, these are the practical routes:

1. Render a high quality intermediate from After Effects. Use a mezzanine format such as ProRes or another lightly compressed codec, which keeps nearly all the quality, at the cost of a large file.
2. Encode that intermediate to H.264 in a separate step. You can do it in Media Encoder, in HandBrake, or in FFmpeg, with a quality value rather than a fixed bitrate. For a 1080p graphic, a CRF around 16 to 18 is a good start. The CRF explanation shows what each value costs in size.
3. Keep the intermediate until you have checked the final.

Splitting the render from the encode also lets you retry the encode quickly without rendering again, which can save hours on a long composition.

A command for step two with FFmpeg:

ffmpeg -i render_prores.mov -c:v libx264 -crf 17 -preset slow \
  -pix_fmt yuv420p -movflags +faststart -c:a aac -b:a 192k final.mp4

Chroma: why colored text looks rough

Most H.264 and H.265 files use a format called 4:2:0, in which the color information is stored at half the width and half the height of the brightness information. Photographs and live action hide this, since color changes slowly in them. Graphics reveal it. A thin red line on a blue box has a sharp color edge, and the file cannot store that edge at full detail.

I tested it with a synthetic test image: red text on a blue box, green text on magenta, and white on dark gray, rendered losslessly and then encoded with x264 at CRF 18 in two pixel formats. I compared the decoded results to the original in RGB. The 4:2:0 file scored 34.22 dB, and the 4:4:4 file scored 53.35 dB. The file sizes were nearly the same: about 35.1 kB against 35.5 kB for a two-second clip.

The 19 dB difference is large, and you can see it as fringing and softness around colored text. White text on gray was fine either way, which fits the explanation, since the problem is in the color planes.

What to do about it:

• If the file is for a platform that re-encodes anyway, such as YouTube, you cannot deliver 4:4:4 usefully, because they will convert it to 4:2:0. In that case, avoid thin saturated edges where you can: make text a little bolder, and give saturated text on saturated backgrounds some luminance contrast, so the brightness channel carries the edge.
• If the file is for a screen you control, such as a trade show display, a 4:4:4 export is possible, but many players and hardware decoders do not handle it, so test on the real device.
• For web and social video, accept 4:2:0 and design for it.

White or light text on a darker background of a different brightness survives best. Two colors with the same brightness but different hue are the worst case, because the brightness plane has nothing to hold on to.

Gradients and banding

A smooth gradient across 1920 pixels needs many steps to look smooth, and an 8-bit image has only 256 steps per channel. A slow gradient from dark blue to slightly darker blue can have just a few steps over the entire width, and each step is a visible band. The compression step then flattens the bands further, since flat areas are cheap.

Three things help:

1. Work in 16 bits per channel in the project settings, so that effects such as blurs and glows compute without rounding into bands. A 16-bit project still ends as 8 bits in H.264, but with better intermediate steps.
2. Add noise or grain to the gradient. A small amount of noise breaks up the bands, and the eye reads it as smooth. Keep it subtle, a few percent. It costs bitrate, because noise is hard to compress, so there is a balance.
3. Give the encoder room. Very low bitrates smooth away fine noise and bring the bands back. A higher quality setting preserves the grain.

Dark scenes are the worst. In my noise tests, noisy material was expensive to encode, and it dropped in quality quickly when the bitrate was fixed. The same effect applies to a carefully dithered gradient: it needs bitrate to survive.

Frame rate, motion blur and shutter

Judder and stepping can be mistaken for low quality. Match the composition’s frame rate to the delivery: 24, 25, 30 or 60 as the project requires. If you animate at 30 and export at 24 by mistake, the program drops frames and movement looks uneven.

Fast moving thin objects look jagged without motion blur, because each frame is a razor sharp snapshot. Turning on motion blur for those layers and for the composition, with a shutter angle around 180 degrees, makes the movement smooth. It also helps the encoder: a blurred edge compresses better than a sharp edge that jumps across the frame. If a fast moving title is breaking into blocks, try a little motion blur before you raise the bitrate.

Higher frame rates cost more, though less than you might guess. In my frame rate test, the same clip encoded at the same quality setting came out at 3,028 kB at 15 fps, 3,159 kB at 24, 3,487 kB at 30 and 4,039 kB at 60. Going from 15 to 60 fps made the file about a third bigger, not four times bigger, because the extra frames are very similar to their neighbors and compress well. If you export 60 fps for a post that plays at 30, you pay that extra for frames nobody sees.

What the platform does to your upload

Even a perfect export gets re-encoded by many platforms. Each re-encode costs quality, and the loss is steepest on detail that is already marginal, such as thin lines and noise. I measured generational loss on a plain clip, encoding the output over and over at CRF 23, and the quality kept falling pass after pass. A graphic with thin lines suffers more.

You can improve the odds. Upload at the size the platform prefers, at a bitrate high enough that its encoder starts from a good picture, and avoid uploading something already compressed hard. The YouTube export guide goes through this for YouTube, and the post on why exports come out pixelated covers the general idea.

Color shifts that look like quality loss

Sometimes a render looks wrong in a different way: the colors are flatter or more saturated than in the composition, and the gradients look less smooth. This often comes from color management differences between the program and the player. Different players treat the color range and the color space of the same file differently, so a file can look washed out in one and correct in another.

I will not say too much about this, because the exact settings depend on your project’s color setup and I have not tested them here. A reasonable approach:

• Pick one color workflow for the project and keep it.
• Tag the output with the right color information when the encoder offers it.
• Check the result in a browser and in a standard player, not only in the editor.
• If colors shift between players, compare against a simple reference, such as a bar test pattern, to see which player is off.

A color shift is not blocking, but people describe both as “bad quality”, so check which one you have.

Check the rendered file, not the project

After rendering, look at the file with an objective tool. FFprobe tells you what you actually made:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,width,height,pix_fmt,r_frame_rate,bit_rate \
  -of default=nw=1 final.mp4

Check that the size is what you intended, the pixel format is what you planned, the frame rate matches, and the bitrate is in the range you meant. A surprising number of blocky exports turn out to have a bitrate of 2 or 3 Mbps because of a preset that was never changed.

Then play it on the largest screen you have, at full size, and pause on frames with text, thin lines and gradients. Zoom in. If you cannot see the problem at 100 percent, nobody else will either.

A checklist for a clean export

1. Composition at the delivery size, with an even number of pixels in each direction.
2. Source assets at or above the size they are used at.
3. Vector layers rasterized continuously.
4. Project in 16 bits per channel if there are gradients or glows.
5. A touch of noise over large smooth gradients.
6. Render quality Best, resolution Full.
7. Motion blur on for fast movement.
8. Render an intermediate or use a high bitrate H.264 route.
9. Encode with a quality-based setting for the final, such as CRF 16 to 18, or an adequate bitrate if the platform asks for one.
10. Inspect the file with ffprobe and your own eyes before delivering.

If the file is already rendered and you cannot go back

Sometimes the project is gone, and all you have is a blocky MP4. You cannot recover the original sharpness, but you can reduce the blocks and soften the worst fringing. A deblock filter followed by mild denoising and a Lanczos upscale is what the tool on this site does. It works better on photographic content than on flat graphics, where the blocks are visible against clean areas, so set expectations accordingly. Try a short clip with the free preview, and see the guide on pixelated video after export for the general steps.

For a very small file that needs a clean result, going back to the project is almost always better than repairing the output.

Common questions

Should I render at a higher resolution than I deliver? Rendering at 4K and scaling down to 1080p can give sharper text, since the downscale averages pixels, but it costs render time. Try it on a short section.

Does bigger always look better? A bigger bitrate stops compression blocks, but it cannot fix a soft source or a half-resolution render.

Is a lossless export worth it? For an archive, yes. For delivery, no. A high-quality H.264 with a CRF near 17 is visually close for most work and much smaller.

Why do my renders differ between machines? Different codecs, effects and color settings, or plugin versions, can change results. Compare the settings first.

Summary

Blocky After Effects exports usually come from one of five places: the render resolution, scaled-up layers, a low bitrate at the encode, chroma subsampling on colored text, or banding in gradients. Set the render to Full and Best, prepare assets at the right size, work in 16 bits where there are gradients, render an intermediate and encode it with a quality setting, and design colored text so that the brightness channel carries the edge. Then check the actual file at full size before you send it.