AI Anime Video Generator Free: Ten Pages, Not One Frame Rate
Ten pages rank for this phrase and not one of them states a frame rate, a drawn-frame count, or whether the motion is generated frame by frame. The sixteen example clips those pages ship were decoded frame by frame instead: every one carries a new image at every frame, none of them behaves like animation drawn on twos, and no page says whether those frames were drawn or filled in afterwards.
- Model
- AI anime video generators, free tiers
- Observed
Not one of the ten pages Google returns for this phrase states a frame rate, a drawn-frame count, or whether the motion is generated frame by frame. The one place the words appear is a sentence saying you will not have to do that work yourself. So the question was taken to the files instead: sixteen example clips shipped by eight of the ten pages were decoded frame by frame, and every one of them carries a new image at every frame — 24, 25 or 30 frames a second in the container, and between 19.4 and 29.4 new images a second in the picture. None of them holds an image long enough to look like anime drawn on twos.
Measured on 24 October 2026 on one Windows machine, in a browser with no account signed in. The pages were read in full and the clips were downloaded from the addresses those pages serve, then decoded locally. What follows separates two questions that are easy to run together: whether each frame of an output is a new picture, and whether that picture was drawn by the model or filled in afterwards. The first is measured here. The second is not, and the reason is set out below rather than papered over.
Why the frame count is the question
Hand-drawn anime rarely draws every frame. A character running is usually drawn on twos, sometimes on threes, and the drawing is held for two or three frames of a 24-frame second while the camera keeps moving. That is why the motion reads as drawn rather than filmed, and it is a deliberate choice rather than a shortcut.
An AI generator that produces anime can land on either side of that line. It can render a new image at every frame, which looks closer to filmed motion and closer to modern digital compositing; or it can generate at a lower rate and hold, which looks closer to the cel work the style comes from. Both are defensible, and they are different products. The free tier does not decide which one you get, and a page that quotes a credit allowance has said nothing about it.
The number also matters for anyone planning an edit. A clip that carries a new image at every frame cuts cleanly against other footage at the same rate. A clip drawn on twos has a rhythm of its own, and cutting it against 30-frame material shows.
What the ten pages say
Every page was read in full, and the whole text was searched for frame rates, frame counts and the vocabulary of animation timing. The result is a column of blanks.
| Page | Rank | Frame rate or drawn-frame count stated | The nearest sentence on the page |
|---|---|---|---|
| crreo.ai | 1 | None | "Stickman Animation" — a style name, no figure |
| kling.ai | 2 | None | No frame wording on the page |
| flick.art | 3 | None | "clean line work, cel shading, and saturated color" — a look, not a rate |
| domoai.app | 4 | None | "Upload 2-8 images. Generate video with smooth transitions between every frame." |
| dreamina.capcut.com (stands in for adobe.com, which refused this browser) | 13 | None | "the Multiframes tool processes up to 10 images individually" |
| vidu.com | 6 | None | "fluid-motion" and "advanced algorithms", no figure |
| viggle.ai | 7 | None | "no animation software, no rigging, no frame-by-frame work" |
| renderforest.com (stands in for canva.com, which served a challenge page) | 15 | None | "Describe your idea and generate an animated video in minutes" |
| openart.ai | 9 | None | "You don't draw frames or write technical prompts" |
| higgsfield.ai | 10 | None | "Impact frames and smears. Sakuga style energy." |
The right-hand column is quoted so the claim being tested stays visible next to the result. Four of those sentences are the closest any of the ten comes, and none of them is a rate: DomoAI is describing a transition between stills you supply, Dreamina a limit on how many stills go in, Higgsfield a drawing style borrowed from hand animation, and Viggle the fact that its tool spares you the work.
That Viggle sentence is worth reading twice, because it is the only place in ten pages where "frame by frame" appears at all, and it appears as a thing you are being spared. It is not a claim about what the output contains.
What the sixteen sample clips contain
Eight of the ten pages ship example clips on the page itself, and those files are the only output-shaped evidence a visitor without an account can get. Sixteen of them were downloaded at their published addresses and decoded: 791 frames in the longest, 121 in the shortest. The other two are excluded for a reason each: the clip on crreo.ai is a brand film that does not claim to be anime output, and the "videos" on dreamina.capcut.com are still images inside video tags, with no moving file served.
Each frame was reduced to a small grey image and compared with the frame before it. A frame counts as new when the average difference across the picture reaches a fixed threshold; dividing the count by the duration gives how many new images the clip actually carries per second. If a clip were drawn on twos, that number would land near 12; on threes, near 8. If it simply repeated frames, the average hold would sit at two or three frames.
| Clip | Picture | Container | Frames | Seconds | New images per second | Frames per image |
|---|---|---|---|---|---|---|
| domoai-hero.mp4 | 1920×1080 | 30 | 597 | 19.92 | 27.56 | 1.09 |
| flick-anime-hero.mp4 | 1920×1088 | 24 | 121 | 5.04 | 23.80 | 1.01 |
| flick-anime-0.mp4 | 1920×1088 | 24 | 121 | 5.04 | 23.80 | 1.01 |
| flick-anime-2.mp4 | 1920×1088 | 24 | 121 | 5.04 | 24.00 | 1.00 |
| flick-anime-4.mp4 | 1920×1088 | 24 | 121 | 5.04 | 24.00 | 1.00 |
| higgsfield-community-1.mp4 | 1248×1664 | 24 | 241 | 10.05 | 23.97 | 1.00 |
| higgsfield-feature-create.mp4 | 1920×1080 | 24 | 361 | 15.07 | 23.36 | 1.03 |
| kling-hero.mp4 | 1920×1080 | 30 | 526 | 17.55 | 26.04 | 1.15 |
| openart-hero.mp4 | 1280×720 | 24 | 361 | 15.04 | 19.41 | 1.24 |
| openart-anime-openings.mp4 | 1920×1080 | 24 | 241 | 10.04 | 19.62 | 1.22 |
| openart-tell-story.mp4 | 1280×720 | 24 | 241 | 10.04 | 20.51 | 1.17 |
| vidu-hero.mp4 | 1920×1080 | 30 | 153 | 5.10 | 29.41 | 1.02 |
| viggle-hero.mp4 | 960×540 | 25 | 535 | 21.40 | 24.25 | 1.03 |
| viggle-step3.mp4 | 1706×1280 | 25 | 791 | 31.64 | 24.97 | 1.00 |
| renderforest-gallery1.webm | 1920×1080 | 24 | 145 | 6.04 | 24.00 | 1.00 |
| renderforest-gallery3.webm | 1920×1080 | 24 | 145 | 6.04 | 22.18 | 1.08 |
The last column is the one that answers the layer. Every clip holds each image for about one frame, and the ones that sit lowest are not holding groups: the three OpenArt files carry 19.4 to 20.5 new images a second because their slow passages change so little between frames that the difference falls under the threshold, and their average hold is 1.17 to 1.24 rather than the 2.0 or 3.0 a stepped clip would show. If any of these were drawn on twos, half the frames would be repeats and the hold would sit at two.
None of the sixteen is limited animation in the cel sense. All of them move like material that has a picture on every frame, which is what a video model producing frames in sequence would give you — and also what a lower-rate render pushed through a frame-rate converter would give you. That ambiguity is the whole of the second question, and the next two sections are about why it stays open.
The instrument was checked before it was used
A frame counter that cannot tell a repeated frame from a moving one will confidently report the wrong answer, and this site has already published one instrument error of exactly that kind. So the detector was run against four clips whose answer was known in advance, built for the purpose.
| Control clip | How it was built | Expected new images per second | Measured |
|---|---|---|---|
| sc_true8_in24.mp4 | eight drawn frames a second, placed in a 24-frame container, each held three frames | 8 | 8.00 (hold 3.00) |
| sc_true12_in30.mp4 | twelve drawn frames a second, placed in a 30-frame container | 12 | 12.00 (hold 2.50) |
| sc_smooth24.mp4 | native 24-frame motion | 24 | 24.00 (hold 1.00) |
| sc_motionblur24.mp4 | native 24-frame motion with temporal blur | 24 | 24.00 (hold 1.00) |
All four came back at the expected value, including the blurred one, where motion blur might have been mistaken for a held frame. Only then were the vendor clips measured.
The check that failed, and why no interpolation claim is made here
The second question — drawn or filled in afterwards — was approached with a separate detector. Its premise was that a clip whose frame rate was raised by averaging neighbouring frames would show it: the inserted frame sits almost exactly at the midpoint of the two around it, so a residual against that midpoint collapses on half the frames and spikes on the rest.
It failed its control. A clip built by hand from a twelve-frame source, with an exact midpoint inserted between every pair, came back at 0.000 against the original rule — the same reading as genuinely continuous motion. A second rule separated that control but then flagged real vendor clips that merely contain still passages, which is a false positive of the same size. Two rules, two failures, and the instrument was thrown out rather than tuned until it agreed with a conclusion.
So this page makes no claim about interpolation, and none about how many drawings a model actually generates. A finished video file cannot settle that on its own, and the ten pages do not disclose it. What is measured here is what a viewer would see: whether the picture changes on every frame.
Why there is no clip of our own in the table
The stronger evidence would have been a clip generated during this measurement, from a prompt, and decoded the same way. That did not happen. Five of the ten pages present an input a visitor can type into, and all five were tried with a ninety-character anime prompt typed through the browser's own input channel: flick.art answered with a sign-in sheet, higgsfield.ai returned 401 on its user endpoint and never issued a generation request, openart.ai returned 401 on its asset endpoints, renderforest.com moved into an editor shell without submitting anything, and domoai.app has no prompt field on the landing page at all. The other five present no input on the page.
Zero outputs, so zero of our own to measure. The sixteen clips above are the pages' own examples, and they are labelled as such throughout — not as something this site produced.
What this page does not establish
Whether the free tier produces the same frame rate as the examples is unknown: the samples are marketing material, and a vendor can render those at a higher setting than a free job. Whether a paid plan exposes a frame-rate choice is also unknown, because no page in the ten has a frame-rate control of any kind.
Whether each frame is generated or interpolated stays open, and the failed instrument above is the reason it is recorded as unmeasured rather than guessed. The pages do not publish the method, and the file does not carry it.
One machine, one browser, one day. A vendor can change its sample clips without announcing it, and this page describes what those files contained on 24 October 2026, at the addresses the pages served that day.
Where the parts of this that can be checked are kept
The decoded frame counts, the per-clip measurements, the control clips and the page text quoted above are dated and stored with the run that produced them, so every figure here traces back to a file rather than to a summary of one. The site's ledger of AI video free tiers — each figure carrying the channel it was observed on, the date, and whether it came from a vendor statement or a single observation — is published as CSV, JSON and Markdown on the data page.