The document route on Wan 3.0 accepts one file, up to 50 pages, up to
100 MB, in docx, doc, xlsx, xls, pptx, ppt, pdf, txt, key,
pages, numbers and md.
Two caps, and people reliably treat them as one. They are not correlated in either direction:
If your uploader only enforces the megabyte cap — which is the easy one, because
the browser hands you file.size for free — then every rejection your users
see will be the page one, and the message will say nothing useful.
You do not need a document parser for the common cases.
PDF — count /Type /Page occurrences, or read the /Count on the page tree
root. A streamed read of the first and last few kilobytes is usually enough.
PPTX / DOCX / XLSX — these are ZIP archives. The slide count is the number of
ppt/slides/slideN.xml entries; you can read the central directory without
inflating anything. Word and Excel are messier (Word has no stored page count
until rendered), but slide decks are the dominant case for this route and they
are the easy one.
Legacy .doc / .ppt / .key / .pages / .numbers — these are the cases
where you either convert server-side or accept that you will be relaying the
API's rejection. Which is fine, as long as you relay it as a page-count
rejection rather than as a generic failure.
Worth knowing, and rarely written down: the 50-page cap is not uniformly enforceable across every accepted format. Some of those twelve extensions carry no reliable page concept until something renders them. Treat "50 pages" as a firm rule for the paginated formats and as a best-effort estimate for the rest, and say so in your error copy rather than asserting a precise count you cannot actually produce.
Fifty pages is the input ceiling. Thirty seconds is the output ceiling. That is 0.6 seconds a page, which is not a compression ratio, it is a change of genre.
At that ratio the model is not walking through your document. It read the document and is directing something new from what it learned. Which is either exactly what you wanted or the opposite of it, and knowing which decides whether this route is right at all — what actually happens to a deck handed to the model goes through the distinction, including which parts of a document survive and which get dropped.
The document route has a sibling: instead of file you may send link, a public
URL, and the model reads the page.
They are mutually exclusive, and there is exactly one of each per job. That means the preparation advice inverts: you can edit a document before you hand it over, and you usually should — strip the appendix, delete the legal boilerplate, cut the slide that is just a table of contents. You cannot edit somebody else's web page, so with a link your only lever is which page you point at.
If the request fails on pages, the useful message has three parts: the count you found, the cap, and the suggestion. "This deck has 78 pages; the limit is 50. Export slides 1–50, or cut the appendix."
Nothing about megabytes. The megabytes were fine.
Document limits on this page were read from Alibaba Cloud Model Studio's Wan 3.0 API reference on 2026-08-25.