PDF mit Passwort schützen — PDF-Verschlüsselung online

Ein Vertrag, ein Ausweisscan, ein ärztlicher Befund, ein Finanzbericht — Dokumente, die man nicht offen liegen lassen darf. Das Werkzeug „Mit Passwort schützen" in pdfredX verschlüsselt ein PDF direkt im Browser: Ohne Passwort öffnet sich die Datei in keinem kompatiblen Viewer. Weder das Dokument noch das Passwort geht an einen Server.

Schritt 01. PDF hochladen

Öffnen Sie pdfredx.com und fügen Sie das Dokument hinzu, das Sie schützen möchten. Die Datei wird lokal im Tab gelesen — nichts wird an einen Server gesendet.

Schritt 02. Ein Passwort festlegen

Aktivieren Sie den Passwortschutz und geben Sie das Passwort zweimal ein (zur Bestätigung). Die Regeln sind einfach: mindestens 6 Zeichen, und beide Felder müssen übereinstimmen. Wählen Sie ein sicheres Passwort — der gesamte Schutz beruht darauf, und es kann bei Verlust nicht wiederhergestellt werden (die Datei wäre nicht mehr zu öffnen).

Schritt 03. Geschütztes PDF herunterladen

Klicken Sie auf „PDF erstellen". Das Dokument wird bereits verschlüsselt erstellt, und der Dateiname erhält den Zusatz _protected. Beim Öffnen fragt jeder Viewer — Adobe, ein Browser, eine mobile App — zuerst nach dem Passwort. Der Download erfolgt direkt aus dem Browser. Kostenlos, ohne Registrierung.

Wie es technisch funktioniert

Das Passwort wird über die Verschlüsselungsoption an den jsPDF-Konstruktor übergeben — das Dokument wird sofort mit aktivierter Standard-PDF-Verschlüsselung (RC4) erstellt. Das ist kein „Schloss über der Datei" und kein Skript-Platzhalter: Der Inhalt selbst (die Seitenströme) wird verschlüsselt, und ein /Encrypt-Wörterbuch wird in die PDF-Struktur geschrieben. Deshalb verlangt jeder kompatible Viewer das Passwort, nicht nur eine bestimmte App. All das geschieht im Speicher des Tabs — das Passwort und die Datei verlassen das Gerät nicht.

Bekannte Einschränkungen

Das Passwort kann nicht wiederhergestellt werden. Wir speichern oder übertragen es nicht — wenn Sie es vergessen, lässt sich das Dokument nicht öffnen. Notieren Sie das Passwort an einem sicheren Ort.

Die Verschlüsselung ist RC4 128-bit, nicht AES-256. Das ist echte „Passwort-zum-Öffnen"-Verschlüsselung, kompatibel mit allen Viewern, und sie genügt, um Außenstehende am Öffnen der Datei zu hindern. Doch RC4 ist ein veralteter Algorithmus: Gegen einen gezielten Angriff mit Spezialwerkzeugen ist er schwächer als modernes AES. Für besonders sensible Dokumente nutzen Sie das Passwort als eine Schicht, nicht als einzige Maßnahme.

Die Stärke des Schutzes = die Stärke des Passworts. Ein kurzes oder offensichtliches Passwort wird per Brute Force geknackt. Verwenden Sie ein langes Passwort aus zufälligen Zeichen.

Möchten Sie eine sichtbare „Kopie"-Marke oder ein Logo setzen, statt die Datei zu sperren? Das ist das Werkzeug Wasserzeichen.

Probieren Sie es gleich aus — pdfredx.com, ohne Registrierung, Ihre Dateien bleiben bei Ihnen.

Sie setzen ein Passwort auf ein PDF, damit ein Außenstehender das Dokument nicht öffnet. Doch ein gewöhnlicher Online-Dienst zum „PDF-Passwortschutz" ist so gebaut, dass Sie dafür sowohl das Dokument als auch das gewählte Passwort auf seinen Server laden müssen. Das ist ein Paradox: Während Sie die Datei schützen, geben Sie sowohl ihren Inhalt als auch den Schlüssel dazu an eine fremde Maschine. Sehen wir uns das Risiko und die lokale Alternative an.

Das Paradox des serverbasierten Passwortschutzes

Der Sinn eines Passworts ist, dass niemand außer Ihnen Zugriff auf das Dokument hat. Doch ein Server-Dienst, der dieses Passwort setzt, erhält sowohl die Datei im Klartext als auch das Passwort. Von dort aus können sie nach der Richtlinie des Dienstes:

• im temporären Speicher eines Auftragsverarbeiters abgelegt werden (AWS, GCP, Azure);
• auf einem fremden Server verarbeitet werden;
• zusammen mit Metadaten protokolliert werden — IP, Zeit, Dateiname.

Selbst wenn der Dienst ehrlich ist, sind Sie gezwungen, ihm sowohl das Dokument als auch den Schlüssel anzuvertrauen.

Der DSGVO-Blickwinkel

Sobald das Dokument auf den Server eines Dienstes hochgeladen wird, findet — wenn personenbezogene Daten enthalten sind — im Sinne der DSGVO eine Übermittlung an einen Dritten statt, mitsamt der zugehörigen Pflichtenkette (AVV, Serverstandort, Rechtsgrundlage). Besonders absurd ist das hier: Sie geben ein vertrauliches Dokument *und* dessen Passwort an genau die Stelle weiter, vor der das Passwort schützen soll. Die lokale Verarbeitung entfernt die Übermittlung — und damit die Pflichtenkette — vollständig.

Lokale Verschlüsselung: Passwort und Datei verlassen das Gerät nicht

pdfredX verschlüsselt ein PDF, ohne weder die Datei noch das Passwort irgendwohin zu laden.

Die Datei wird lokal gelesen. Das Dokument öffnet sich im Tab; es gibt keine Netzwerkanfrage mit ihm.

Das Passwort bleibt im Speicher des Tabs. Es wird direkt an die jsPDF-Verschlüsselung übergeben und nirgendwo gespeichert — weder bei uns noch im Netz.

Die Verschlüsselung läuft auf dem Client. Das Dokument wird bereits verschlüsselt erstellt (Standard-PDF-Verschlüsselung), und ein /Encrypt-Wörterbuch wird in die Datei geschrieben — ohne Passwort in keinem kompatiblen Viewer zu öffnen.

Es funktioniert offline. Laden Sie die Datei, trennen Sie die Internetverbindung und setzen Sie das Passwort — alles läuft weiter. Das Netz wird nur benötigt, um die App einmal zu laden.

In der Praxis: Aktivieren Sie den Schutz, geben Sie das Passwort zweimal ein, klicken Sie auf „PDF erstellen" — Sie erhalten eine verschlüsselte Datei. Sowohl das Dokument als auch das Passwort bleiben die ganze Zeit nur bei Ihnen.

Ehrlich zu den Einschränkungen

Die Verschlüsselung ist RC4 128-bit, nicht AES-256. Das ist echter „Passwort-zum-Öffnen"-Schutz, kompatibel mit allen Viewern, doch RC4 ist ein veralteter Algorithmus und schwächer als AES gegen einen gezielten Angriff. Für besonders sensible Dokumente kombinieren Sie das Passwort mit anderen Maßnahmen.

Das Passwort ist nicht wiederherstellbar. Wir speichern es nicht — vergessen Sie es, lässt sich die Datei nicht öffnen.

Lokale Verarbeitung ist kein Schild gegen alles. Schadsoftware auf dem Gerät, Browser-Erweiterungen mit weitreichenden Rechten und eine unverschlüsselte Festplatte bleiben außerhalb unserer Kontrolle. Wir gewährleisten die Isolation auf Ebene des Browser-Tabs; der Rest liegt beim Nutzer.

Setzen Sie ein Passwort, ohne das Dokument auf einen Server zu laden — pdfredx.com, kostenlos, ohne Registrierung.

„Ein Passwort auf ein PDF setzen" kann sehr Verschiedenes bedeuten — von ehrlicher Inhaltsverschlüsselung bis zu einer Imitation, die nur vorgibt zu schützen. Der Unterschied ist entscheidend: Manche Methoden verlangen das Passwort in jedem Viewer, andere werden in zwei Klicks umgangen. Sehen wir uns an, wie der Passwortschutz in pdfredX aufgebaut ist: warum die Verschlüsselung im Dokument-Konstruktor gesetzt wird, was in das /Encrypt-Wörterbuch kommt und wo die Grenze zwischen RC4 und AES-256 verläuft.

Was „echte" PDF-Verschlüsselung ist

Das PDF-Format hat einen eingebauten Sicherheitsmechanismus (den Standard Security Handler): Der Inhalt (Seitenströme und Objekte) wird verschlüsselt, und ein /Encrypt-Wörterbuch mit Parametern wird zur Dokumentstruktur hinzugefügt. Ein Viewer, der auf /Encrypt trifft, muss nach dem Passwort fragen und die Daten mit einem daraus abgeleiteten Schlüssel entschlüsseln. Der Kernpunkt: Der Inhalt selbst wird verschlüsselt — ohne Passwort gibt es in der Datei keinen lesbaren Text und keine Bilder.

Das unterscheidet sich grundlegend von „weichen" Fälschungen — etwa in ein PDF eingebettetem JavaScript, das ein Passwortfenster zeigt und das Dokument schließt. Ein solches Skript funktioniert nur in Viewern, die PDF-JS ausführen (Adobe Acrobat), während der Inhalt im Klartext liegt und von jedem anderen Werkzeug gelesen werden kann. pdfredX verwendet genau die eingebaute Verschlüsselung, keinen Skript-Platzhalter.

Die Umsetzung im Einzelnen

Die Verschlüsselung wird beim Erstellen des Dokuments gesetzt

Die zentrale Einschränkung der Engine: Die Verschlüsselung in jsPDF wird nur im Konstruktor aktiviert, nicht nachträglich. Deshalb wird das Passwort vor dem Erstellen des Dokuments abgefragt und geprüft und dann in die Optionen übergeben:

const pdfPwd = getPdfPassword();               // ≥6 Zeichen, Bestätigung stimmt überein
const pdfOpts = { orientation, unit: 'mm', format: 'a4' };
if (pdfPwd) pdfOpts.encryption = { userPassword: pdfPwd, ownerPassword: pdfPwd };
const pdf = new jsPDF(pdfOpts);                // das Dokument wird bereits verschlüsselt erstellt

userPassword ist das Passwort zum Öffnen, ownerPassword das zum Ändern von Rechten; hier sind sie gleich (ein einfaches „Passwort-zum-Öffnen"-Modell). Die Seiten werden dann wie üblich hinzugefügt, doch bei der Ausgabe (pdf.output) sind alle Ströme bereits verschlüsselt, und /Encrypt wird in die Struktur geschrieben.

Das Ergebnis überprüfen

Dass ein verschlüsseltes Dokument tatsächlich verschlüsselt ist, sieht man direkt in den Bytes:

const bytes = pdf.output('arraybuffer');       // nach /Encrypt und einem Klartext-Leck suchen
// im Ergebnis: "/Encrypt" und der Standard-Handler sind vorhanden,
// während die Inhalt-Markerzeichenkette in den Bytes FEHLT — der Inhalt ist verschlüsselt.

Genau so wurde das Verhalten getestet: In der verschlüsselten Datei wird die Markerzeichenkette nicht gefunden, in einer normalen schon. Das Passwort wird von jedem kompatiblen Viewer verlangt, nicht nur von Acrobat.

Alles lokal

Das Passwort wird direkt an jsPDF im Speicher des Tabs übergeben und nirgendwo gespeichert. Die Datei wird auf dem Client erstellt — weder das Dokument noch der Schlüssel geht ins Netz.

RC4 vs AES-256: die ehrliche Grenze

jsPDF implementiert den Standard Security Handler auf dem Algorithmus RC4 (128-bit). Das ist echte Verschlüsselung, kompatibel mit allen Viewern, und sie schließt das Dokument zuverlässig vor beiläufigem und gewöhnlichem Zugriff ab. Doch RC4 ist eine veraltete Stromchiffre: Gegen einen gezielten Angriff mit Spezialwerkzeugen ist sie schwächer als modernes AES-256, das neuere Versionen des PDF-Standards verwenden.

Die ehrliche Schlussfolgerung: Für „damit ein Außenstehender es nicht öffnet" reicht ein RC4-Passwort; für Dokumente, bei denen der Preis einer Kompromittierung hoch ist, sollte es eine Schutzschicht sein, nicht die einzige. AES-256 clientseitig erfordert eine andere Krypto-Bibliothek — ein möglicher nächster Schritt.

Kompromisse und Grenzen

Das Passwort ist nicht wiederherstellbar — es wird nirgendwo gespeichert; vergessen Sie es, lässt sich die Datei nicht öffnen.

Stärke = Stärke des Passworts. Ob RC4 oder AES, ein kurzes Passwort wird per Brute Force geknackt. Sie brauchen ein langes zufälliges Passwort.

Schützt nicht vor Bedrohungen auf dem Gerät — Schadsoftware, Erweiterungen, eine unverschlüsselte Festplatte liegen außerhalb der Kontrolle des Browser-Tabs.

Was als Nächstes kommt

AES-256 — Umstieg auf den modernen Algorithmus über eine separate Krypto-Bibliothek für Dokumente höherer Sensibilität.

Zugriffsrechte — ein separates Owner-Passwort mit feiner Steuerung (kein Drucken/Kopieren) zusätzlich zum Öffnen-Passwort.

Testen Sie es an Ihrem eigenen Dokument — pdfredx.com, ohne Registrierung, die Datei und das Passwort bleiben bei Ihnen.