Using Flowing Content for Dynamic Page Generation
Learn how Flowing Content handles variable-length text across generated pages, with repeating elements, page numbers, API rendering, and layout controls.

When text length varies, a fixed-size text box can leave a document with clipped text, overflow, or type that has been shrunk until it is hard to read. Orshot describes Flowing Content as a text mode that continues content that does not fit on the initial page onto as many generated overflow pages as needed. You design one template page, set the text element to Flow, and let rendering add pages as the content requires. [Read Orshot’s announcement](https://orshot.com/blog/introducing-flowing-content).
This is useful for reports, articles, invoices, receipts, certificates, and legal or compliance documents whose text length is not known when the template is designed. Repeating headers, footers, and logos can be carried onto overflow pages; page-number variables can identify the current and total page count. The details below reflect Orshot’s April 29, 2026 announcement. Its credit and plan statements are time-sensitive vendor claims, so confirm current terms before budgeting a production workflow.
1. What Flowing Content does
Flowing Content is an overflow behavior for a text element. Instead of forcing all supplied text into the original text area, the renderer continues it on additional generated pages. The purpose is to preserve the content and avoid manually predicting how many pages a particular input will need.

| Behavior | What happens when text is too long | Tradeoff |
|---|---|---|
| Shrink to fit | The text becomes smaller to fit the original area. | Can undermine readability when the input is much longer than expected. |
| Truncate | Text after the available area is omitted. | Content is lost; unsuitable when the complete document matters. |
| Allow overflow | Text extends beyond its intended container. | May collide with other elements or fall outside the page. |
| Flow | Text continues onto generated overflow pages. | Page count and layout must be considered as part of the output. |
Flowing Content does not remove the need to design a page system. It changes the behavior of the text element; you still decide the text region, what repeats, and how page breaks should look. The announcement describes PNG, JPEG, WebP, PDF, and video output support. Choose the format according to how the generated document will be consumed: a PDF for a multipage document, or an image format when a rendered page or visual asset is the required deliverable.
2. Configure a template in Studio
- Open the template you want to use in Orshot Studio.
- Select the text element that may receive variable-length content.
- In the Styles panel, set Text Autofit to Flow.
- Mark any header, footer, or logo that should appear on continuation pages as Repeat on overflow pages.
- If page numbering is needed, add
{{_page_number}}and{{_total_pages}}to a repeating text element. - Add representative short and long content and inspect the preview, including the overflow pages.
The preview is a key part of template design: a first page that looks balanced with short text may not leave room for a footer or may create an awkward final page with long text. Check the result at realistic content lengths before using the template in a workflow.
Choose what repeats deliberately
Headers, footers, and logos are common repeating elements, but not every element should repeat. A one-time title, opening illustration, or section label may belong only on the first page. Decide which information must travel with every page so a reader can identify the document and its context when pages are separated.
Keep repeating elements clear of the flowed text region. If the text area and a repeated footer compete for the same vertical space, the page can be technically generated but visually crowded. Design a consistent safe area for the body text, then check both the first page and an overflow page in preview.
3. Page numbering and continuation layout
The announcement identifies two variables: {{_page_number}} for the current page and {{_total_pages}} for the total page count. Add them to a text element that repeats on overflow pages when readers need navigation such as “Page 2 of 5.” Because total pages depend on the rendered content, use the variables rather than hard-coding a page count into the template.

Orshot also describes Flow Zones, which specify the Y position and height of text on overflow pages. This gives the template author control over where continuation text starts and how much vertical room it can use. Consider whether the first page has a different layout from subsequent pages: a cover-like first page might have a title area, while later pages can begin the body higher up. Flow Zones are the described control for tailoring text placement on overflow pages.
For documents that need predictable reading order, inspect where breaks occur around headings, lists, signatures, totals, or clauses. The announcement describes page-break granularity at line, word, or character level, and minimum-line settings before and after a break to help control widows and orphans. These settings matter because a technically valid page break can still leave a heading stranded at the bottom or a single line isolated at the top.
Preserve inline styling
Orshot says bold, italic, color, and inline rich-text styling carry over page breaks. If the supplied content uses emphasis to distinguish labels, clauses, or warnings, check a long example that breaks in the middle of styled content. The announcement describes style carry-over, but does not publish a complete rich-text input schema; use the format supported by your template and integration rather than assuming a particular markup syntax.
4. Render variable-length content through the API
The launch announcement shows an ordinary render request: pass long text in the modifications object and request PDF output. It says the response indicates generated pages and includes totalPages and flowTotalPages fields. The source does not give the endpoint URL, authentication scheme, full request envelope, or a complete runnable API payload, so those must come from current Orshot API documentation and your account configuration. Do not copy a guessed endpoint or field casing into production.
At the integration level, the flow is:
- Choose the Flow-enabled template.
- Supply the variable text as a modification for its text element.
- Request the desired output format, such as PDF for a multipage document.
- Read the rendered result and its page-count metadata.
- Store or deliver the result only after checking that the render succeeded and the page count is within your application’s expected limits.
The following is deliberately a shape example, not a runnable Orshot request. Consult Orshot’s current API documentation for the required URL, headers, authentication, request fields, and response handling:
// Conceptual request shape only; obtain the exact schema from Orshot documentation.
{
"modifications": {
"body_text": "Variable-length content supplied by your application"
},
"format": "pdf"
}
// The announcement says the render response includes page-count fields:
// totalPages and flowTotalPages
Use your actual template element identifier in place of body_text if the API schema requires one. Treat field names in this conceptual example as explanatory, not confirmed API names. For production code, validate the payload against the current documentation or API schema, and handle the returned artifact according to the documented response type.
5. Decide how to handle page count and delivery
Flowing Content makes output page count dependent on content length and layout. Your application should be prepared for a variable number of pages. Display or store the returned page metadata where it is useful, and set application-level expectations for unusually large inputs. For example, a workflow that normally creates a short invoice may need a review path if supplied content unexpectedly produces a long document.
The announcement names totalPages and flowTotalPages, but does not define their exact relationship or guarantee how every format represents pages. Confirm their semantics in current API documentation before using them for billing, page limits, or business rules. In particular, do not assume that an image render and a PDF render expose identical page structures just because multiple output formats are supported.
6. Output formats and use cases
| Need | Possible format | What to verify |
|---|---|---|
| Multipage report, article, invoice, or formal document | Page count, page breaks, repeated elements, and final-page appearance. | |
| Raster page images | PNG, JPEG, or WebP | How the chosen render represents generated pages and how your delivery pipeline consumes them. |
| Rendered video output | Video | How the template and flowing text are represented in the specific video workflow. |
Orshot’s announcement lists these formats as supported, but it does not provide format-specific limits or a detailed explanation of how a multi-page flow maps into each output. Confirm the behavior you need before selecting a delivery format. For documents that need printing or page-by-page review, PDF is the natural format to evaluate first; for other formats, check how the renderer packages pages and what your downstream consumer expects.
7. Quality checklist before shipping
- Test short, typical, and unusually long content.
- Confirm the text is set to Flow on the intended element.
- Check that headers, footers, or logos repeat only where intended.
- Verify page variables on both the first page and overflow pages.
- Inspect breaks around headings, lists, signatures, and other meaningful boundaries.
- Review Flow Zone position and height on continuation pages.
- Check the final page for excess whitespace or a stranded final line.
- Confirm the output format and returned page metadata match your integration’s assumptions.
- Verify current credit and plan terms against Orshot’s current account or product documentation.
8. Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| Text is still reduced to fit or does not continue. | The selected text element is not set to Flow, or the wrong element is being modified. | Reopen the template, select the intended element, and confirm Text Autofit is Flow. Confirm the API modification targets that element. |
| Continuation pages omit the logo or footer. | The element is not marked to repeat on overflow pages. | Enable Repeat on overflow pages for each element that should recur, then inspect the preview. |
| Page numbers are missing or identical. | The variables are absent, misspelled, or placed in a non-repeating element. | Use the documented variable spellings {{_page_number}} and {{_total_pages}} in an element that repeats. |
| Text begins too high or too low on later pages. | The overflow text placement does not fit the continuation-page design. | Adjust the Flow Zone Y position and height, then review with realistic long content. |
| A page break leaves an awkward single line or separates a heading. | Break granularity or minimum-line settings do not suit the content. | Review line, word, or character break behavior and minimum lines before and after a break. Inspect the actual preview. |
| The API render fails or the result has no expected page metadata. | The request shape, authentication, format, or response assumptions may not match the current API. | Use current Orshot API documentation for the endpoint, required fields, authentication, and response schema. The launch article alone is not a full API reference. |
| PDF pages look right but a raster or video result does not match expectations. | Output formats may package or represent page output differently. | Validate the exact output format in the intended delivery workflow; the announcement does not spell out each format’s page mapping. |
9. Performance, reliability, and cost
Flowing Content can remove a manual page-count decision from a variable-length document workflow, but the available announcement gives no render-time benchmarks, maximum content size, concurrency limit, or service reliability figures. Do not estimate throughput or promise a rendering time from this source. If latency matters, measure the end-to-end workflow with representative content in your environment and account for the variable number of generated pages.
For reliability, make the render step observable in your application: retain the request identifier or other documented correlation data, record the returned status and page metadata, and provide a way to retry or review failures according to Orshot’s API guidance. Validate long content and unusual formatting, because those are the cases most likely to reveal layout problems. The announcement does not specify retry guarantees or idempotency behavior; consult current documentation before automatically retrying a request that may have completed.
The April 29, 2026 announcement states that each generated output page costs one credit and that Flowing Content is available in Orshot Studio on all plans. These are vendor-reported terms at publication time, not independently verified current pricing. Since flowing may increase the number of output pages, estimate credit use from expected page counts, then confirm the current credit rules and plan terms before launch. The dossier does not provide a price per credit or a complete cost schedule.
10. Or skip the browser setup
If your task is to capture a web page as an image or PDF rather than generate a paginated document from a template, ScreenshotNeo is a separate option: it is a website screenshot API and MCP server. One GET request takes a URL and returns a screenshot or PDF. It does not replace Flowing Content’s variable-length template pagination.
For this screenshot use case, a one-call capture looks like this. See the ScreenshotNeo API documentation for the full options:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
- Cookie banners, popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
- Bot checks, blank pages, timeouts, and failed loads are not billed; response headers report the page verdict and billing status, and cache hits cost nothing.
- An MCP server provides
take_screenshot,get_page_info, andcapture_pdftools for Claude, Cursor, and other MCP clients. - The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Every feature is on every plan.
Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.
11. Frequently asked questions
Does Flowing Content require a separate template for every page?
The announced workflow starts with one template page and generates overflow pages as the text requires. You can mark selected elements to repeat on those pages.
Can I use it for a fixed-length document?
You can, but its main value is handling content whose length varies. For fixed content, preview the resulting layout and decide whether the extra overflow behavior is useful for your template.
Can I control how a paragraph splits?
The announcement lists line, word, and character break granularity, plus minimum-line settings before and after a break. Use the Studio controls and preview the specific content to judge the result.
Is the one-credit-per-page statement guaranteed to be current?
No. It is what the April 29, 2026 announcement says. Confirm current credit and plan terms with Orshot before relying on it.
Is ScreenshotNeo a way to generate overflow pages from template text?
No. ScreenshotNeo captures websites as screenshots or PDFs. Flowing Content is the relevant feature when the job is to paginate variable-length text in a template.


