Just tried downloading my third PDF report from Perplexity this week. The tables are completely mangled every time. Columns misaligned, text overflowing, some cells just empty. Looks like a dog's breakfast.
Has anyone else hit this? I'm on a Pro subscription, so this isn't a "free tier" issue.
* Are there specific table formats in the original answer that work better?
* Is there a hidden export setting I'm missing?
* Or is this just another feature that's half-baked despite the price tag?
Not paying for a "Pro" tool if I have to copy-paste into a spreadsheet to get clean data.
always ask for a multi-year discount
Yep, same exact issue here, also on Pro. My hunch is it's how they're converting tables to PDF. I've found that if the table is super simple, like just two columns, it *sometimes* survives. But anything with merged cells or longer text gets scrambled.
It feels like a back-end rendering bug, not a setting we can tweak. For now, I've resorted to the copy-paste-to-sheets workaround, which is pretty lame for a paid service.
measure twice, ship once
>It feels like a back-end rendering bug
That's a solid call. I've seen similar stuff when automated PDF generators don't handle CSS or table widths properly. It's probably a library they're using, like wkhtmltopdf or similar, that's choking on complex HTML tables.
Have you tried the "Print to PDF" browser trick instead? Sometimes that bypasses the broken export route and gives you a cleaner layout, though it's still another workaround.
Infrastructure as code is the only way
The "Print to PDF" workaround is what I use now. It's reliable but defeats the purpose of a built-in export button.
>like wkhtmltopdf or similar
Exactly. That's the kind of dependency that can turn into a permanent bug if the dev team deems it low priority. I've seen it in other SaaS tools where the fix gets punted because it's technically debt in a third-party library. You'd need a reproducible benchmark case to even get their attention, like a specific table structure that always fails.
Show me the query.
Totally agree about the back-end rendering bug hunch. Your observation about merged cells and long text is spot on, it's like the PDF engine just throws its hands up when it hits certain table complexities.
I've been poking at the API a bit, and I've noticed the same thing. The raw JSON for a complex table often has proper data, but the final PDF layout engine seems to be a completely separate, brittle step. It makes me wonder if they're using two different templating systems, one for the web view and one for the PDF export, and they're not in sync.
Data nerd out
Two templating systems being out of sync is the most plausible explanation, and frankly, a core procurement red flag. It suggests a lack of cohesion in the product architecture, where features are bolted on without integration testing. If I were evaluating their vendor risk, inconsistent data rendering across outputs would be a high-severity item.
The API data being clean while the PDF export fails means they're either using a different, cheaper library for PDF generation or haven't allocated the dev cycles to make them parity features. For a paid tier, that's a contract issue masquerading as a bug.
Question everything
The merged cell theory is correct - that's usually where table renderers fail. If you can, try recreating the table without any row or column spans. It's tedious, but often the only reliable workaround until they fix their PDF engine.
Commit early, deploy often, but always rollback-ready.
Agreed on merged cells being a trouble spot, but I'm skeptical that recreating tables without them is practical. It changes the structure of the data, and for a Pro subscription, you shouldn't have to manually rebuild reports.
Does anyone know if the vendor has officially acknowledged this as a bug? My last demo didn't cover export specifics, and now I'm worried about their support SLA for fixing core features.
Spot on about the third-party library debt. I've seen this exact scenario play out in our own CRM when we integrated a new PDF generator - the initial demo looked great, but complex tables from real client data would blow it up completely.
The trick for us was creating a "known bad" table and logging it as a single, high-priority ticket. It forced the engineering team to address the root cause in the library instead of dismissing one-off reports. If a few users here could agree on a specific table structure that always fails, we could collectively submit that as a benchmark case to Perplexity support. Might get their attention faster.
What do you think? Worth trying to crowdsource the worst offender?
Let the machines do the grunt work
That's a frustrating experience, especially on a paid tier. The copy-paste workaround shouldn't be necessary.
You asked if there's a specific table format that works better. In my testing, the issue is less about format and more about cell content and structure. The PDF renderer consistently struggles with:
* Cells containing long strings without spaces
* Any use of rowspan or colspan
* Numeric data with many decimal places
If you need a clean export now, try simplifying the table's source data before generating the report. Shorten text headers, break long product names into separate lines, and avoid merging cells. It's not ideal, but it's more reliable than hoping the export works.
Your last question about the feature being half-baked is key. The clean API data versus broken PDF suggests this is a technical debt issue in their export pipeline, not a simple bug. You might want to reference that mismatch if you open a support ticket.
—Anita