How are AI features priced?

AI features are included in every plan at no additional cost. We don't charge per-token or add AI surcharges.

Yes, all our products come with robust REST APIs, webhooks, and SFTP integration options for enterprise workflows.

Where is data processed?

Data is processed securely in US-based data centers with SOC 2 Type II compliance, AES-256 encryption, and full audit logging.

Can I try before I buy?

Yes, most of our products offer free trials or free tiers so you can evaluate before committing.

What kind of support do you offer?

We offer email support for all plans, with priority support and dedicated account managers for higher tiers.

Privacy & Compliance

cloudHQ vs ThreadPDF: Where Your Emails Go When You Click Export

Published May 12, 2026 · ~10 minute read

Your firm has been retained to represent a client in a contract dispute. A partner asks you to compile a year of email correspondence with opposing counsel into a single PDF for the case file. You install a Chrome extension, click Export, and a few seconds later a PDF lands on your disk.

Between "click Export" and "file on disk," where did those emails travel? Whose servers did they touch? Are they still there?

For two of the most-installed Gmail-to-PDF extensions — cloudHQ's Save Emails to PDF (100,000+ users) and ThreadPDF — the answers are different in ways that matter specifically to lawyers, healthcare providers, accountants, and anyone bound by a data processing agreement that restricts third-party processing.

This post reads cloudHQ's own published documents and compares the two architectures. We're not arguing cloudHQ is careless — they have credible security practices that we'll spell out. We're arguing that server-side anything is structurally incompatible with certain compliance regimes, regardless of how well it's implemented.

The two data flows, side by side

Both products show you the same UI inside Gmail: select threads, click a button, get a PDF. What happens in between is where they diverge.

cloudHQ (server-side)

  Browser (Gmail tab)
        |
        | OAuth: gmail.readonly
        v
  cloudHQ extension
        |
        | HTTPS upload (email
        |   content + metadata)
        v
  cloudHQ backend
        |
        | render HTML -> PDF
        |
        v
  Browser downloads PDF
        |
        v
  PDF on your disk

Your email content traverses cloudHQ infrastructure and is processed by cloudHQ before the generated PDF is returned to your browser.

ThreadPDF (on-device)

  Browser (Gmail tab)
        |
        | OAuth: gmail.readonly
        v
  ThreadPDF extension
   (runs in your browser)
        |
        | render HTML -> PDF
        |   (entirely in
        |    extension JS)
        v
  Browser memory
        |
        v
  PDF on your disk

  [no server hop]

Email content never leaves the browser process. The HTML-to-PDF render happens inside the extension's own JavaScript context using Gmail's API response, then the resulting bytes are saved via the browser's standard download mechanism.

What cloudHQ's documents say

cloudHQ's privacy policy also asserts:

“cloudHQ is sync and replication service so no data is persistently stored on cloudHQ servers.”
— cloudhq.net/privacy

That statement describes cloudHQ's general posture across its products. For teams with strict retention or data-flow requirements, the practical vendor-review question is still straightforward: confirm exactly how Save Emails to PDF handles generated export files during and after conversion.

cloudHQ's terms of service also include a broad data-handling grant that's worth quoting:

“By allowing our Service to manage your data, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, and prepare derivative works.”
— cloudhq.net/terms

This language is standard for SaaS Terms of Service. It exists to give the provider legal cover for the technical operations they need to perform — copying bytes through servers, generating derivative files (like PDFs), and so on. It is not evidence of bad intent. It is, however, language you cannot accept on behalf of a client whose emails you hold in trust without thinking about the consent chain.

What "on-device" means in practice

A Chrome extension is a self-contained JavaScript bundle that runs inside the user's browser process, sandboxed to the permissions declared in its manifest.json. When ThreadPDF generates a PDF, the relevant operations happen in three places, all local:

Read. The extension calls Gmail's REST API from the user's browser, using the user's OAuth token. The response — raw message HTML — is delivered to the extension's JavaScript context, not to any third party server.
Render. The extension uses a client-side PDF library to convert the HTML to PDF bytes in memory. No network round trip is involved in the conversion.
Save. The PDF blob is handed to the browser's download API, which writes it to the user's configured downloads folder.

The traffic graph for that workflow is a star with two points: Google's servers and the user's browser. There is no conversion-server vertex. The extension also includes a Switch Labs host permission for subscription and account-status checks, so the important audit question is whether email content is posted to any non-Google conversion endpoint during export.

The architectural consequence is that ThreadPDF's privacy posture is verifiable in a way that any server-side product's cannot be: you (or your security team) can load the extension, open Chrome DevTools' Network tab, and watch every request the extension makes during an export. If a request goes anywhere other than *.googleapis.com or your own organization's telemetry endpoint, the product is misbehaving and you can prove it.

Compare that to a server-side product, where the only visibility you have into what happens after upload is what the vendor chooses to publish in their privacy policy.

What cloudHQ does well on privacy

It would be easy to write this comparison as “server-side bad, on-device good.” That framing is lazy and ignores the actual security work cloudHQ has done. A fairer reading of their security page includes the following:

Encryption at rest. “Every account cloudHQ protects receives a unique AES 256-bit encryption key.” cloudHQ does not publicly break out whether generated PDF export objects use the same control, so regulated buyers should confirm that point during vendor review.
Encryption in transit. “Communication between cloudHQ servers and Google, Microsoft, Box, and Dropbox servers is always done over a secure TLS v1.3 channel.”
Inherited infrastructure certifications. “Our infrastructure respects and maintains industry-standard security certifications, including ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, FedRAMP ATO and PCI DSS v3.2.” This is infrastructure-level language; teams that require a cloudHQ-specific SOC 2 or product audit report should request it directly from cloudHQ.
Stated non-persistence posture. Their privacy policy includes the line “We never store your emails, files or any other documents,” reflecting the company's intent to function as a sync/replication layer rather than a long-term store.

None of this is window dressing. Encryption at rest, TLS in transit, and inherited cloud provider certifications are the baseline a competent SaaS vendor should hit, and cloudHQ hits them. If you are evaluating server-side Gmail-to-PDF tools against each other, cloudHQ is a reasonable choice.

The argument of this post is narrower: for certain use cases, the choice between “encrypted server-side processing” and “no server-side processing” is not a matter of degree. It is a binary.

When does this actually matter?

Run yourself through this checklist. If you check any box, on-device processing is likely a requirement, not a preference.

HIPAA covered entity or business associate. Patient communications that pass through an un-BAA'd third-party processor are a reportable incident. cloudHQ does not publish a Business Associate Agreement for this product on its public site, so covered entities should confirm BAA availability directly before use.
Attorney-client privileged correspondence. Some bar opinions treat sending privileged material through a third-party cloud processor as a potential waiver unless the processor is bound by appropriate confidentiality terms. The standard fix is to keep privileged communications inside the firm's own technology perimeter.
Cross-border data transfer restrictions. Server-side processing can add jurisdiction and data-flow questions. If your DPA prohibits transfers outside specific jurisdictions (EU-only, US-only, in-country), you cannot use a vendor whose data flow you do not control.
Customer DPAs that prohibit new processors. Many enterprise customer contracts include a clause that forbids you from adding new processors without prior written notice. Routing customer email through any server-side export vendor can trigger that review.
SOC 2 / ISO 27001 audit scope. If your company is in an active audit, adding a server-side email processor expands your audit scope and creates a new vendor due-diligence file. An on-device extension that touches only the user's browser typically does not.
Government, defense, or FedRAMP-aligned work. cloudHQ's security page references “FedRAMP ATO” for its underlying infrastructure, but inherited FedRAMP and a cloudHQ-specific FedRAMP authorization are different things. Request product-level authorization evidence if your program requires it.
Internal “no third-party email processors” policy. Some organizations have a blanket rule, often born of a past incident, that email content cannot pass through any vendor other than the email provider itself. On-device tools satisfy this rule trivially; server-side tools cannot.

When server-side is fine

The honest counter: most Gmail-to-PDF users are not in any of the categories above, and for them, cloudHQ's architecture is fine.

You are probably fine with server-side processing if:

You are an individual archiving personal emails for your own records.
You are a marketing team archiving customer-facing email campaigns for analytics.
You are exporting non-confidential business correspondence — quotes from public information, public meeting minutes, newsletter content.
Your organization has no DPA constraints, regulated data, or active compliance audit.
You specifically need cloudHQ's integrations with Box, Egnyte, Salesforce, or other destinations they support that on-device tools do not.

For these users, the comparison comes down to price, feature completeness, and brand familiarity, which is a different conversation. See our full feature-by-feature comparison of ThreadPDF and cloudHQ for that breakdown.

If on-device matters to your use case

ThreadPDF is a Chrome extension that exports Gmail threads to PDF, HTML, or plain text, with optional attachment bundling, processed entirely in your browser. Free for up to 5 threads per day; $4.99/month or $49.99/year for unlimited exports.

Install ThreadPDF for Gmail →

Or read the side-by-side comparison with cloudHQ for pricing, features, and where each tool fits best.

Sources cited

cloudHQ Privacy Policy — https://www.cloudhq.net/privacy
cloudHQ Terms of Service — https://www.cloudhq.net/terms
cloudHQ Security — https://www.cloudhq.net/security
Save Emails to PDF by cloudHQ — Chrome Web Store listing — Chrome Web Store

All cloudHQ quotes in this post were retrieved from the URLs above on 2026-05-13. If cloudHQ updates their policies, the quotes here may no longer match. Where public documentation was ambiguous, this post says so directly rather than treating unanswered vendor-review questions as confirmed facts.