AES-128 or AES-256: What Actually Decides Your PDF's Encryption Strength

Ask five different documentation pages how PDF4me encrypts a file, and four of them will happily tell you it uses AES encryption. Ask which strength, AES-128 or AES-256, and none of them will give you a parameter to set. That is not a gap in the docs. It is the actual answer.

What the password field protects, and what it doesn't

PDF4me's Protect endpoint takes a password and a permission flag, and it is worth being precise about what each one actually does, because they protect against completely different things. The password gates opening the file at all. Anyone without it is locked out entirely. The permission flag gates what happens after the file is already open, for someone who does have the password.

That distinction matters more than it sounds like it should. A confidential PDF sent to a single recipient probably wants a real password and a generous permission flag; the file stays private in transit, and once the right person has it, they can do what they need to. A read-only contract or a proof copy that needs to circulate more widely might skip a meaningful password (or share it openly) and instead lean on the permission flag to block printing, editing, or redistribution once opened. Same endpoint, two very different jobs, one call.

On the REST API, this is a required field in the request body: POST /api/v2/Protect, with password as a string and pdfPermission as an enum. It is not optional the way async is. Skip it and the call fails outright.

The question the title asks, and the honest answer

Here is where it gets interesting. Nothing in the request lets you choose AES-128 over AES-256, or the reverse. There is no encryptionStrength field, no algorithmType, nothing. The docs page's own FAQ answers the "what decides it" question directly: PDF readers apply 128-bit or 256-bit AES depending on the PDF version of the source file you sent in. Not a setting you pick. An inherited property of the document you started with.

Practically, that means the honest way to influence key strength isn't a parameter on this endpoint at all, it's whatever produced the PDF in the first place. A file authored or converted to a modern PDF version tends to land on the stronger 256-bit path. An older-format PDF, the kind that's been through several rounds of scanning, re-saving, or a legacy export pipeline, is more likely to land on 128-bit, regardless of how badly you'd prefer otherwise when you call Protect. If key strength genuinely matters for a specific document, the place to intervene is upstream, at conversion or generation time, not at the encryption call itself.

This is worth sitting with for a second, because it runs against how a lot of automation gets built. It's tempting to assume every meaningful behavior of an API is something you configure. Here, the more accurate mental model is: you control who can open the file and what they can do once inside. You do not control, from this call, exactly how strong the underlying cipher key is. That's decided further back in the file's own history.

The permission flag, one at a time

pdfPermission is an allow-list, not a deny-list, worth internalizing before picking a value. Whatever is not explicitly permitted gets blocked.

• All permits everything: printing, copying, editing, annotating, filling forms. Use it for password-only protection where the goal is purely gating who can open the file, with no further restriction once they're in.
• None is the most restrictive option available. It blocks printing, copying, editing, annotating, and form filling, leaving only the ability to open and read.
• Copy permits opening plus copying text or images out, and blocks everything else, including printing.
• Annotate permits sticky notes and highlights on top of opening, while still blocking copying, printing, and editing.
• Fill Forms permits filling in form fields specifically, useful for confidential intake forms where the recipient needs to complete something but shouldn't be able to redistribute or edit the underlying document.
• Support Disabilities permits screen readers and other assistive tooling, relevant for anyone building accessible-by-default document workflows.
• Assemble permits page-level operations: inserting, deleting, or rotating pages, which matters if a downstream automation needs to restructure the file after it's been protected.
• Digital Print permits low-resolution printing only, blocking high-resolution output and copying, a reasonable middle ground for proof copies that need to circulate for review without becoming a distributable, print-ready original.

The request itself

A minimal password-only call, everything else allowed:

{
  "docContent": "JVBERi0xLjQK...",
  "docName": "invoice.pdf",
  "password": "Str0ng-P@ss!",  "pdfPermission": "All",
  "async": false
}

The maximum-restriction version changes exactly one field:

{
  "docContent": "JVBERi0xLjQK...",
  "docName": "confidential.pdf",
  "password": "Str0ng-P@ss!",  "pdfPermission": "None",
  "async": false
}

Sent synchronously (async: false), the response is HTTP 200 with the encrypted PDF returned directly as raw binary bytes, Content-Type: application/pdf, no JSON wrapper. Write the response body straight to a file. Sent asynchronously, the response is HTTP 202 with a Location header; poll that URL until it resolves to 200 with the same binary body. The asynchronous path is the better default for large files or anything running as part of a batch, the same pattern PDF4me uses across its other processing endpoints.

A quick curl version of the same call:

curl -X POST https://api.pdf4me.com/api/v2/Protect \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic YOUR_API_KEY" \
  -o protected.pdf \
  -d '{"docContent":"JVBERi0xLjQK...","docName":"invoice.pdf","password":"Str0ng-P@ss!","pdfPermission":"Fill Forms","async":false}'

Before wiring this into anything live, PDF4me's guide to connecting to the API covers authentication and the base URL if this is the first call you're making against this API.

Want to confirm a file's protection status before or after calling this? Get PDF Information returns encryption status alongside other document metadata, useful as a quick verification step in a pipeline.

Not the same thing as a signature

Worth flagging before wiring this into a workflow that also cares about document integrity: Protect and Digital Sign are answering different questions. Protect controls who can open a file and what they can do with it once inside. Digital Sign applies a cryptographic signature layered on top of, or instead of, password protection, aimed at tamper-evidence for legal and compliance-sensitive workflows rather than access control. A contract that needs to prove it hasn't been altered after signing needs the signing endpoint. A confidential file that just needs to stay private in transit needs Protect. Some documents reasonably need both, applied as two separate calls.

Unlock PDF is the direct inverse of Protect: given the correct password, it strips protection back off, useful anywhere a downstream step in a pipeline needs the original, unencrypted file back for further processing.

Same call, four no-code platforms

The REST API's Protect action is available as its own module or connector on every no-code platform PDF4me supports, using the same core fields (a source file, a password, a permission choice): Power Automate, Make, Zapier, and n8n. None of the four introduce an encryption-strength selector either, since the underlying mechanism is identical, just wrapped in each platform's own trigger-and-action interface instead of a raw REST call. If a workflow needs to encrypt PDFs the moment a new file lands in a watched folder, gets flagged in a form submission, or clears an approval step, the module or connector fires the same Protect call this article walks through, whatever tool is orchestrating it.

The REST API can also be tested interactively, with a real file, through PDF4me's API Tester, before any of this gets wired into a live automation.

Before you set this up

Ask what the password and the permission flag are each actually meant to do here, since conflating them is the easiest mistake. If the goal is keeping a file private in transit to one recipient, the password does the real work, and the permission flag can stay generous. If the goal is controlling what a recipient can do with a file they're expected to have, the permission flag is where the real decision happens, and the password becomes closer to a formality.

And if AES key strength specifically matters for a document, that's not a field on this call to look for. It's a property already baked into the PDF you're encrypting, decided by whatever produced it. Chase that upstream, not here.

Website: pdf4me.com

Documentation: docs.pdf4me.com

Developer portal: dev.pdf4me.com