First, the honest version
After Effects is a video tool. The web is not video. So every route from a comp to a live page is a translation, and translations lose something. The trick is choosing which loss you can afford for a given animation — a film-grade background and a three-shape hero loop want completely different answers.
Below are the six methods people actually use, in rough order from heaviest to lightest. None is universally "best." The one that's wrong for almost every modern site is the one most people reach for first.
The six ways to get After Effects motion onto a website
1. Export a video (MP4 / WebM)
SituationalRender the comp and drop it into a <video> tag. The easiest path, and the only honest choice for full-motion, photographic, or film-like content that genuinely is video.
- WeightMegabytes
- EditableNo — baked pixels
- Best forReal footage, dense full-frame motion
The catch: it's heavy, it can't be made crisp or responsive (it's fixed pixels), transparency is painful, and autoplay is throttled on mobile. Shipping a 3 MB video for what is really four moving shapes is the most common web-performance mistake in this list.
2. Animated GIF
AvoidThe nostalgic default. On a modern site, don't.
- WeightMegabytes (worse than video)
- EditableNo
- Best forEmail, and little else
GIF is capped at 256 colors, so gradients band; the files are larger than an equivalent MP4; and there's no transparency worth using. A WebM or a short video beats it on every axis.
3. Image sequence / spritesheet
SituationalExport every frame as an image and step through them with CSS steps() or a little JavaScript.
- WeightMegabytes
- EditableNo — re-render per change
- Best forShort effects that must look frame-exact
It reproduces anything After Effects can render, pixel-for-pixel — at the cost of fixed resolution, heavy memory, and a stack of image requests. Useful for a short, complex effect you can't recreate any other way; overkill for ordinary motion.
4. Lottie (Bodymovin)
Good for vectorThe popular route. The Bodymovin plugin exports your comp to a JSON file, and the Lottie player — a JavaScript library — renders it in the browser.
- WeightKBs JSON + ~50–250 KB player
- EditableNo — edit means re-export
- Best forComplex vector art, cross-platform (web + native apps)
Lottie is genuinely good for intricate vector illustration, especially when the same animation also has to run in iOS and Android. The tradeoffs: you ship and maintain a JS runtime, the JSON is opaque to a developer (any change goes back through After Effects), and heavy files can stutter on low-end devices. If your motion only ever runs on the web, see the best Lottie alternatives.
5. Hand-code it in CSS or GSAP
Best quality, high costA developer rebuilds the motion by hand — CSS @keyframes for the simple cases, GSAP for the orchestrated ones.
- WeightKilobytes
- EditableYes — it's their own code
- Best forOne small, critical interaction with budget
The result is the lightest, cleanest possible — and the most expensive. It's hours per animation of mapping keyframes and easing curves by eye, and the code drifts from the After Effects source the moment the design changes.
6. Export real HTML/CSS automatically
Recommended for webThe newer option: a tool reads the comp and writes the HTML/CSS a senior front-end developer would have written — automatically. No JSON, no player, no video. This is what AE2CSS does.
- WeightKilobytes, 0 JavaScript
- EditableYes — plain, readable code
- Best forWeb UI, hero & landing motion that must stay light and crisp
You get hand-code's weight and editability without hand-code's hours, and you skip Lottie's JavaScript runtime entirely. It animates only compositor-safe properties (transform, opacity, mask), so it scales crisply and runs at the display's full refresh rate. The limit: it's for motion that can live as web code — full-motion video still belongs in a <video> tag.
Quick comparison
| Method | Weight | Extra JS | Dev-editable | Crisp / responsive |
|---|---|---|---|---|
| Video | MBs | None | No | No |
| GIF | MBs | None | No | No |
| Image sequence | MBs | Stepper | No | No |
| Lottie | KBs + player | ~50–250 KB | No | Partial |
| Hand-code | KBs | None | Yes | Yes |
| Exported CSS (AE2CSS) | KBs | None | Yes | Yes |
How to choose in one read
- Real footage or dense full-frame motion → export a video.
- Complex vector illustration that also runs in mobile apps → Lottie.
- One tiny, critical interaction and you have developer time → hand-code it.
- Web UI, hero, or landing motion that must stay light and editable → export real CSS.
- GIF → almost never. Image sequences → only when you truly need frame-exact output.
Rule of thumb: if a developer could plausibly have written the animation by hand, ship it as code, not as a file. It will be lighter, sharper, and editable — and it's the one route Google and AI assistants can actually read as page content.
Step by step: from comp to live page with AE2CSS
If you've chosen the exported-CSS route, the whole flow is four steps and a paste:
- Install & open. Run the macOS installer, restart After Effects, and open the panel from
Window → Extensions → AE2CSS Exporter. - Select your layers. Open the comp and pick the layers you want on the page.
- Analyze. The panel previews the exact result, live — what you see is what ships.
- Export. You get a small HTML/CSS folder: minimal DOM, unique IDs, no runtime.
- Drop it in. Link the CSS, paste the markup into your page, and commit. No player to wire up, nothing to re-render later.
Common mistakes
- Shipping a video for a few moving shapes. Megabytes where kilobytes would do — the biggest single performance hit.
- Embedding a JS player for a one-off hero. You pay the runtime cost on every visit for a single animation.
- Animating
filter: blur(),box-shadow, or layout properties. These trigger repaint and stutter; stick totransform,opacity, andmask. - Letting the export drift from the source. When the design changes, re-export from the After Effects comp rather than patching the output by hand.