Solving DeepL Character Limits: Why We Moved PDF Processing Back to the Popup

Working with large PDF translations is rarely just about extraction or formatting.

Sometimes, the real challenge lies in how the process is triggered and sustained.

Recently, we ran into a limitation that forced us to rethink our entire workflow design.

The goal: seamless PDF processing with readable outputs

One of our improvements involved formatting extracted data — including dates — directly in the main interface.

The idea was simple:

• Upload a PDF
• Extract content
• Process it via DeepL
• Display results in a clean, readable format

Including properly formatted dates so users don’t have to interpret raw or technical output.

Everything should feel immediate and understandable.

A structural change in workflow execution

To improve control, we initially moved the conversion process away from the internal extension page and triggered it directly through the popup.

On paper, this seemed more stable and direct.

In practice, it revealed a serious limitation.

The 15,000 character problem

Once the input exceeded roughly 15,000 characters, the process began to fail.

It would simply stop continuing.

Even after internal optimizations, we could not reliably reach the expected scale of ~120,000 characters in testing — a requirement raised by real usage scenarios.

This made one thing clear: the current execution model was not stable enough for large-scale processing.

Why internal execution was breaking down

The issue wasn’t just performance.

It was reliability.

When processing was handled inside the extension’s internal page:

• Connections could be interrupted
• State could become inconsistent
• DeepL communication could break mid-process

And once that happens, large translations become unreliable by design.

Rethinking where the process should live

To guarantee stability, we had to reconsider something fundamental:

Where should the process actually start and run from?

After analysis, the conclusion became clear:

The safest and most stable trigger point is the popup itself.

Why the popup is more reliable

By starting and controlling the process directly from the popup:

• The lifecycle becomes simpler
• The connection stays consistent
• There is less risk of internal interruption
• DeepL communication remains stable

In short: fewer moving parts means fewer failure points.

And for large-scale document processing, that matters more than anything else.

Stability over convenience

At first, moving everything into an internal page felt more flexible.

But flexibility is useless if the system breaks under load.

So we prioritized:

• Stability
• Predictability
• Consistent execution

Even if that meant rethinking the architecture again.

Understanding real-world limits

This experience also highlighted an important constraint:

DeepL itself introduces practical limits depending on usage patterns and context.

Even if our system improves, external boundaries still exist — and must be accounted for in the design.

A clearer direction forward

With this change, we now have:

• A more stable process trigger
• Better handling of large inputs
• Reduced risk of mid-process failures

And a clearer understanding of where complexity belongs — and where it doesn’t.

The takeaway

When systems scale, small architectural decisions become critical.

Where a process starts is just as important as what it does.

Building for reliability first

This update reinforces a core principle we follow:

A workflow is only as strong as its weakest connection.

And in this case, simplifying the execution path made the entire system stronger.

Try a more stable workflow

If you’ve ever experienced interruptions during large file processing or translation tasks, you know how frustrating it can be.

Try a system designed for stability from the ground up — and see how much smoother large-scale workflows can become when nothing breaks halfway through.