Send PDF files without compression, signups, or third-party retention

The PDF problem isn't size. A 50-page contract with signatures sits at 2 to 5 MB; even a 1,000-page legal filing rarely tops 500 MB. The problem is that the file has to arrive untouched. A signed PDF, a notarised affidavit, a tax return, or a medical record going to a specialist stops being legally or clinically valid the moment something re-encodes the bytes.

Signature IntegrityWhy a compressed PDF can break a contract

A digital signature on a PDF is a cryptographic hash of the document bytes, signed with a private key. PAdES (the ETSI standard most e-sign tools use) and PKCS#7 (the older Adobe approach) both hash the bytes, sign the hash, and embed the signature inside the file. The Wikipedia entry on digital signatures puts it plainly: a forger "can't sign a different message, or even change a single digit in an existing message without making the recipient's signature verification fail" (source).

The same property that protects you from forgery also breaks the signature when a well-meaning compression tool re-saves the file. Smallpdf's "Compress PDF" product, for example, opens the document, downsamples embedded images, re-encodes the streams, and writes a new file. The output is smaller and visually identical, but it's a different sequence of bytes. The signature's hash no longer matches, and any verifier (Adobe Acrobat, court e-filing systems, a bank's contract intake) flags it as invalid.

The fix isn't a better compression algorithm. The fix is don't compress signed PDFs at all. sto.care doesn't. The bytes you upload are the bytes the recipient downloads.

RetentionWhat free online PDF compressors do with your file

The other quiet problem with browser PDF tools is what happens after the "done" screen. iLovePDF's security page is direct: "all files processed within our platform are automatically and permanently deleted within two hours of being processed" (source). Two hours is short by industry standards. It's also not the retention window you want for a contract you'd rather not sit on a third-party server at all.

The same page carves out an exception: "we retain signed documents for a maximum of 5 years in compliance with legal requirements". Smallpdf publishes similar language about temporary processing storage. A PDF compressor, by definition, has to read your file, write a new copy, and hand the new copy back. That copy exists somewhere, for some window, on a server you don't control.

sto.care holds your file for the explicit window you agreed to, seven days, then purges it via S3 lifecycle and DynamoDB TTL. No second copy, no re-encoded variant cached for "up to 24 hours", no carve-out for signed instruments.

WorkflowHow to send a PDF through sto.care

1. Drag the PDF onto the upload zone. It uploads to S3 over TLS, with no intermediate processing.
2. Type the recipient's email. They get a download link in their inbox; no account needed.
3. We email you a confirmation with a revoke button. Click it any time before the 7-day timer expires.

Use CasesWhere bit-for-bit delivery matters

• Signed contracts and NDAs. A re-saved PDF with a broken PAdES signature isn't a contract; it's a draft.
• Medical records. Provider signatures auditors check. Personal use, not a HIPAA workflow.
• Legal filings. E-filing systems verify embedded signatures; a compressed copy fails intake.
• Tax returns to an accountant. IRS-signed transcripts lose integrity if a compressor rewrites them.
• Background-check results. Employer verification relies on the PDF's signature.

ComparisonHow the alternatives line up

smallpdf and ilovepdf are PDF utility suites; their compress and convert features are the product, so retaining the file long enough to process it is unavoidable. WeTransfer doesn't compress, but its three-day free window is shorter than most contract-review cycles and has no revoke. Email attachments preserve the bytes but live in two inboxes indefinitely. sto.care is pure transit: no processing, hard expiry, optional early kill switch.

PrivacyWhat we see and don't see

Files travel browser-to-S3 over TLS. S3 writes them to disk with AES-256 server-side encryption under AWS-managed keys. That is server-side, not end-to-end: AWS holds the keys, so a compelled disclosure could in theory reach the file before the seven-day purge. For most PDF workflows (a signed lease, a tax return, records you'd also send by email) that's a stronger guarantee than the alternatives. For threat models that include a subpoena to AWS, an end-to-end-encrypted tool with client-side keys is the right choice instead.

We don't read PDF contents. No OCR, no metadata extraction, no model training. The bucket is private, signed URLs are short-lived and per-request, and the DynamoDB TTL drops the row 48 hours after the file expires.

FAQCommon questions

For the broader privacy story, read about encrypted file transfer and share file no signup. If you're weighing this against a familiar default, compare directly with Google Drive.