Das PDF-Format und das Trennen von Seiten: Wie ein Splitter technisch funktioniert

Eike-Christian Ramcke

Geschäftsführer AKARA Solutions, Schwerpunkt Dokumentenformate und Datenschutz

Aktualisiert: Juni 2026

Wer ein PDF in einzelne Seiten zerlegt, erwartet meist, dass die Software die Datei irgendwie auseinanderschneidet. Tatsächlich passiert etwas anderes, das viel schonender ist: Ein Splitter liest die innere Struktur des Dokuments, sucht die gewünschten Seiten heraus und baut um sie herum ein neues, vollständiges PDF. Die eigentlichen Seiteninhalte, also Text, Bilder und Vektorgrafiken, werden dabei Byte für Byte übernommen. Verstehen Sie diesen Mechanismus, wird klar, warum gutes Trennen verlustfrei ist, warum verschlüsselte Dateien Probleme machen und warum das alles ohne Server direkt im Browser laufen kann.

Ein PDF ist kein Bild, sondern ein Objektgraph

Das Portable Document Format wurde 1993 von Adobe eingeführt und ist seit 2008 als offener Standard ISO 32000-1 normiert. Ein PDF ist im Kern eine Sammlung nummerierter Objekte, die aufeinander verweisen. Es gibt acht grundlegende Objekttypen: Boolean, Zahl, String, Name, Array, Dictionary, Stream und das Nullobjekt. Aus diesen Bausteinen wird die gesamte Dokumentstruktur zusammengesetzt.

Entscheidend für das Trennen ist die hierarchische Anordnung dieser Objekte. An der Spitze steht der Document Catalog, das Wurzeldictionary. Er verweist auf den Page Tree, einen Baum aus Knoten vom Typ Pages und Blättern vom Typ Page. Jedes Page-Objekt ist ein Dictionary, das auf seinen Inhaltsstrom (Content Stream) und auf ein Ressourcen-Dictionary zeigt. Im Ressourcen-Dictionary stehen die Schriften, Bilder und Grafikzustände, die diese Seite benötigt.

Am Ende jeder PDF-Datei steht außerdem die Cross-Reference Table (Querverweistabelle, kurz xref). Sie funktioniert wie ein Inhaltsverzeichnis und nennt für jedes Objekt seine exakte Byte-Position in der Datei. Ein PDF-Leser springt über diese Tabelle direkt zu den benötigten Objekten, statt die ganze Datei sequenziell zu durchsuchen. Genau diese Tabelle muss ein Splitter beim Trennen komplett neu schreiben, weil sich in der neuen Datei alle Byte-Positionen verschieben.

Was beim Trennen wirklich passiert: Kopieren statt Schneiden

Ein Splitter geht in vier Schritten vor. Erstens parst er die Quelldatei, liest also die xref-Tabelle und baut den Objektgraphen im Speicher auf. Zweitens legt er ein leeres Zieldokument an, das zunächst nur aus einem Katalog und einem leeren Seitenbaum besteht. Drittens kopiert er die ausgewählten Page-Objekte aus der Quelle in das Ziel, und zwar samt aller Objekte, auf die diese Seiten verweisen: Inhaltsströme, Schriften, Bilder, Grafikzustände. Viertens schreibt er das Zieldokument heraus, vergibt neue Objektnummern und erzeugt eine frische xref-Tabelle.

Der wichtige Punkt: Die Inhaltsströme werden nicht interpretiert oder neu erzeugt, sondern als Binärdaten unverändert übernommen. Ein JPEG, das in der Quelle steckt, landet bitidentisch in der Zieldatei. Eine eingebettete Schrift wird unverändert mitkopiert. Deshalb spricht man von verlustfreiem Trennen: Es gibt keinen Re-Encoding-Schritt, der Artefakte erzeugen könnte.

Warum keine Neukomprimierung nötig ist

In einem PDF sind die Inhalte bereits komprimiert. Textströme und Vektorbefehle werden meist mit dem Flate-Filter (dem aus zlib bekannten Deflate-Algorithmus, definiert in RFC 1951) gepackt. Bilder tragen ihren eigenen Filter, etwa DCTDecode für JPEG oder JPXDecode für JPEG 2000. Diese Filterangabe steht im jeweiligen Stream-Dictionary unter dem Schlüssel /Filter.

Ein Splitter muss diese komprimierten Daten gar nicht auspacken. Er übernimmt den Stream inklusive seiner Filterangabe unverändert. Der Ziel-Reader weiß dadurch weiterhin, wie er den Inhalt zu dekodieren hat. Würde der Splitter stattdessen jedes Bild dekodieren und neu als JPEG speichern, entstünde Generationsverlust, also die typische Verschlechterung bei wiederholter verlustbehafteter Kompression. Genau das verhindert das reine Kopieren der Streams.

Ein konkretes Beispiel: Trennen mit pdf-lib im Browser

So sieht das Prinzip in JavaScript aus. Die Open-Source-Bibliothek pdf-lib lädt die Quelldatei, erzeugt ein neues Dokument und kopiert die gewünschten Seiten hinein. Die Methode copyPages übernimmt dabei automatisch alle Ressourcen, die eine Seite braucht.

import { PDFDocument } from 'pdf-lib';

// Quelle aus dem File-Input lesen (bleibt lokal im Browser)
const bytes = await file.arrayBuffer();
const src = await PDFDocument.load(bytes);

// Neues Zieldokument fuer die Seiten 1 bis 3
const out = await PDFDocument.create();
const indizes = [0, 1, 2]; // 0-basiert: Seite 1, 2, 3
const seiten = await out.copyPages(src, indizes);
seiten.forEach((s) => out.addPage(s));

// Ergebnis als neue PDF-Bytes, kein Upload noetig
const result = await out.save();

Bemerkenswert ist, was hier nicht passiert: Es gibt keinen fetch-Aufruf, keine Serverkommunikation. Die Datei wird mit arrayBuffer() in den Arbeitsspeicher der Browser-Registerkarte geladen, dort verarbeitet und als Download wieder ausgegeben. Genau auf diesem Prinzip basiert die clientseitige Verarbeitung von pdf-trennen.de: Ihre Dokumente verlassen das Gerät nicht.

Die Grenze: verschlüsselte und geschützte PDFs

PDF kennt eine eingebaute Verschlüsselung. Ist sie aktiv, werden alle Strings und Streams im Dokument mit einem symmetrischen Verfahren verschlüsselt, in modernen Dateien mit AES-256 nach ISO 32000-2. Der Schlüssel wird aus einem Passwort abgeleitet. Dabei unterscheidet der Standard zwei Rollen: das Benutzerpasswort (User Password) öffnet das Dokument, das Eigentümerpasswort (Owner Password) hebt zusätzlich Nutzungsbeschränkungen auf, etwa ein Verbot des Druckens oder Kopierens.

Für einen Splitter bedeutet das eine harte Grenze. Solange die Streams verschlüsselt sind, kann er die Seiteninhalte nicht lesen und damit nicht in eine neue Datei kopieren. Ohne den korrekten Schlüssel ist kein verlustfreies Trennen möglich. Der Schutz lässt sich nicht umgehen, er muss zuerst regulär mit dem Passwort entfernt werden. Erst danach liegt ein lesbares PDF vor, das sich trennen lässt.

Ein häufiges Missverständnis betrifft das Eigentümerpasswort. Manche PDFs lassen sich ohne Passwortabfrage öffnen, erlauben aber laut ihren Berechtigungsflags kein Bearbeiten. Diese Flags sind allerdings nur Hinweise an gut gemeinte Software, technisch kein wirksamer Schutz. Eine echte Verschlüsselung mit Benutzerpasswort dagegen ist kryptografisch und ohne Passwort nicht zu durchbrechen.

Was außer den Seiten verloren gehen kann

Seiteninhalte sind nur ein Teil eines PDF. Es gibt dokumentweite Strukturen, die nicht zu einer einzelnen Seite gehören und beim Trennen besondere Aufmerksamkeit verlangen. Dazu zählen Lesezeichen (im Standard Outlines genannt), interaktive Formularfelder (AcroForm), digitale Signaturen, Dokument-Metadaten und seitenübergreifende interne Verlinkungen.

Das Problem ist logischer Natur. Ein Lesezeichen, das auf Seite 40 zeigt, ergibt keinen Sinn mehr, wenn die Teildatei nur die Seiten 1 bis 10 enthält. Ein interner Link von Seite 3 auf Seite 50 läuft ins Leere, sobald Seite 50 fehlt. Die meisten Splitter lösen das, indem sie solche Strukturen entweder weglassen oder nur die Teile übernehmen, die innerhalb der kopierten Seiten gültig bleiben. Eine digitale Signatur wird beim Trennen grundsätzlich ungültig, weil sie genau die unveränderte Gesamtdatei bestätigt, die durch das Trennen nicht mehr existiert.

Für die Praxis heißt das: Reiner Seiteninhalt überträgt sich zuverlässig und verlustfrei. Wenn Sie auf Lesezeichen, ausfüllbare Formulare oder Signaturen angewiesen sind, prüfen Sie das Ergebnis gezielt, denn diese Elemente sind kein garantierter Bestandteil einer getrennten Datei.

Häufige Fragen zur Technik des PDF-Trennens

Quellen und weiterführende Standards

• ISO 32000-1:2008, Document management, Portable Document Format, Part 1: PDF 1.7. iso.org
• ISO 32000-2:2020, Portable Document Format, Part 2: PDF 2.0 (Verschlüsselung mit AES-256). iso.org
• Adobe, PDF Reference and PDF 32000 (offene Spezifikation des Formats). opensource.adobe.com
• RFC 1951, DEFLATE Compressed Data Format Specification (Grundlage des Flate-Filters). rfc-editor.org
• pdf-lib, Dokumentation zum Kopieren und Zusammenfügen von Seiten im Browser. pdf-lib.js.org
• MDN Web Docs, Blob.arrayBuffer (lokales Lesen von Dateien im Browser). developer.mozilla.org

Verwandte Artikel