From AI Slop to Executive Reports: Announcing the All-New, In-Browser AI Author

We kept crashing our own tool during testing, and it taught us something worth shipping: the bottleneck in AI-generated reports was never the writing, it was three embedded logos. That's the story behind this release. Artificial Intelligence has fundamentally broken the speed of writing — but it hasn't fixed the nightmare of formatting, and it turns out the formatting problem and the image-memory problem are the same problem.

Whether you are a founder compiling a project proposal, a freelancer drafting a legal contract, or a student assembling a research report, the modern workflow remains frustratingly manual. You prompt ChatGPT, Claude, or Gemini; you get back brilliant, raw text; and then you spend the next two hours fighting with Microsoft Word or Google Docs margins, broken tables, and shifting bullet points.

The Engineering Problem: Turning Markdown Into a Laid-Out Document

Building a client-side document generator requires bridging two incompatible models. Markdown — as defined by the CommonMark specification most AI models default to when asked for formatted text — is a fluid, structural syntax with no notion of a page. A PDF has pages, fixed margins, and content that has to break sensibly across them. You cannot simply "paste" markdown into a PDF: something has to decide what is a heading, what is a table, and where page four ends.

Most "AI document builders" dodge this by sending your text to a server, using a headless browser (like Puppeteer) to render a webpage, and printing that page to PDF in the cloud. This is slow, expensive, and it means your draft board report is now on someone else's machine. Utilitly's AI Author does the whole thing in the tab, in two stages.

Stage one is recognition, not parsing. AI Author walks your markdown line by line and classifies each one into a typed block — heading levels one through three, paragraph, bullet list, table, divider, or image. It is deliberately not a full CommonMark AST parser; it is a pragmatic scanner tuned for the shape of text that language models actually emit, which is why pasting a messy ChatGPT answer tends to come out sensibly structured rather than literally.

Stage two is layout. Those blocks become @react-pdf/renderer components — the same declarative model as React, but rendering to a PDF document instead of the DOM. Crucially, this means nobody is computing X/Y coordinates by hand. You describe a heading followed by a table; the renderer's flexbox-style layout engine measures the text, decides where lines wrap and where pages break, and emits the PDF. Getting page-break behaviour right is the part that would be miserable to hand-roll, and it is exactly the part you get for free by choosing a real layout engine over a coordinate-plotting library.

[The In-Tab Generation Pipeline]

[Raw Markdown]
       │
       ▼
[ Line scanner ]  "## Q3 Results"        → heading, level 2
                  "| Region | Rev |"     → table block
                  "- Grew 14% YoY"       → bullet list
                  "![](logo.png)"        → image block
       │
       ▼
[ Typed block list ]  ← what the editor shows you, and what you can still edit
       │
       ▼
[ @react-pdf/renderer ]
   - template components style each block type
   - layout engine measures text and breaks pages
       │
       ▼
[ Blob (PDF) ] ──► [ Local Download ]
      

Why Client-Side Image Processing Crashes the Browser (And How We Fixed It)

Text coordinates are computationally cheap. High-resolution images are not. The failure point of most local PDF generators is the browser's heap memory limit. This is not a hypothetical: during internal testing, dropping three 12MB, 300-DPI corporate logos into a single report layout reliably triggered an out-of-memory (OOM) tab crash in Chrome — the exact failure this release was built to fix, not a theoretical edge case we reasoned about in advance.

The fix is unglamorous and it happens the moment you add the image, not at render time. Every image dropped into AI Author is drawn onto an off-screen canvas, scaled down so its longest edge is at most 800 pixels, and re-encoded as a JPEG at 0.8 quality. What the document holds from that point on is the downsampled version — the original full-resolution file is never carried through the layout, and never ends up in the PDF.

[Image dropped: 4000 × 3000, 12 MB PNG]
              │
              ▼
   [ Off-screen canvas ]
   - longest edge capped at 800px
   - re-encoded as JPEG, quality 0.8
              │
              ▼
   [ Downsampled image, held in the editor ]
              │
              ▼
   [ @react-pdf/renderer embeds it at layout time ]
      

It is a blunt cap rather than a per-slot calculation — the renderer doesn't tell the uploader how many millimetres wide the image will end up, so 800px is chosen to comfortably exceed what any slot in the templates needs at print resolution. Blunt is fine here: the thing that crashed the tab was carrying several 12MB decoded bitmaps at once, and capping every one of them on the way in removes that failure mode entirely.

In-Browser Execution for Corporate Data

If you are generating board reports, financial projections, or legal contracts from AI outputs, the structural integrity of your toolchain is paramount. Uploading strategic corporate data to an unverified third-party rendering server is an unnecessary operational risk — and, per the OOM issue above, it was also the thing that was actually breaking on us, not just a theoretical concern.

Because the block recognition, the image downsampling, and the PDF rendering all happen in your browser tab, your text and images are not sent to a rendering service. You can confirm it the same way you would confirm it for any tool making that claim: open the Network tab and watch what fires when you hit Generate. Navigate to the AI Author Tool on Utilitly.com and compile your next report.