ブラウザだけで PDF をオフライン圧縮する方法

どんな PDF が「圧縮されない PDF」か

PDF のサイズが膨らむ主因は本文テキストではなく、ページに埋め込まれた画像です。スキャナで取り込んだ書類、スマホで撮った領収書を貼り付けた経費精算、スクリーンショットを大量に並べた仕様書などは、ページ 1 枚あたり数百 KB〜数 MB の JPEG / PNG ストリームを抱えています。元の解像度が 300 dpi 相当のままだと、A4 1 ページで 2480 × 3508 px のラスタデータをそのまま保持することになり、20 ページのスキャン PDF が簡単に 50 MB を超えます。

Gmail の添付上限は 25 MB、求人応募フォームや行政手続きの提出フォームは 5 MB 〜 10 MB に絞っているケースが少なくありません。受け取り側のメールサーバーも、ウィルス検査の前段で巨大添付を弾くことがあります。「PDF を相手に届ける」段階で詰まらせないためには、画像中心 PDF のサイズを 1/3 〜 1/10 に落とす必要があり、これがブラウザだけで完結する PDF 圧縮 のユースケースです。

ブラウザだけで圧縮する手順

pdf-compress ツール を開き、圧縮したい PDF をドラッグ & ドロップ (複数まとめて投入可) します。読み込み後に 2 つのスライダー、最大画像幅 (px) と JPEG 品質 (0〜100) が表示されます。最大画像幅はラスタライズ時の解像度を抑える設定で、A4 を画面表示やプリンタ印刷で読める範囲に保つなら 1500 〜 2000 px、メール添付目的なら 1200 px まで下げても文字は読めます。JPEG 品質は 60 〜 75 が実用的なバランス点で、それ未満にすると文字エッジに JPEG 特有のリンギング (にじみ) が出ます。

圧縮を実行すると、元 PDF と新 PDF のサイズ比較と削減率が表示されます。複数ファイルを投入した場合は ZIP でまとめてダウンロードできます。PDF を 1 つも送信していないため、DevTools の Network タブを開いたまま操作しても、圧縮処理に関連する HTTP リクエストは流れません (初回のスクリプト・WASM 取得を除く)。

画像再エンコードと不要オブジェクト削除のどちらが効くか

画像中心の PDF では、削減率の支配項は再エンコードです。各ページを canvas にラスタライズし直すと、元の PDF が抱えていた重複オブジェクト・サムネイル・OCR レイヤー・編集履歴・添付ファイル (PDF/A 用のメタデータ、署名済み版のバックアップなど) はすべて落ちます。1500 px / 品質 70 の組み合わせで、写真スキャン PDF はおおむね元の 20 % 〜 40 % まで縮みます。

逆に「テキスト中心の PDF を圧縮しても効果が薄い」のはここに理由があります。文字や図形が PDF の本来のベクトル表現で書かれているドキュメントは、もともと不要オブジェクトが少なく、ラスタライズ + JPEG 化はむしろベクトル情報を失わせて品質を落とします。テキスト PDF を小さくしたいケースでは、ページ削除や PDF 結合・分割 で必要なページだけ抜き出す方が、品質を保ったままサイズを下げられます。

アップロード型 PDF 圧縮との違い

「PDF 圧縮」を検索すると、ブラウザでファイルを選んでサーバーに送信する Web サービスが多数並びます。これらは見た目こそ似ていますが、契約書・履歴書・領収書・人事資料を相手側サーバーへコピーする点で構造的にリスクを抱えます。多くのサービスの利用規約には「アップロードしたコンテンツに対する非独占的なライセンスを当社に許諾する」旨の条項が入っており、削除を申し出ても CDN キャッシュ、ログ、バックアップに残った断片までは追跡できません。

ブラウザ内圧縮はファイルを送る経路自体がコードに存在しません。pdf-compress は pdf-lib と Canvas API、ブラウザの JPEG エンコーダだけで構成されており、ソースは GitHub で監査できます。「圧縮した瞬間にどこにも送られていない」ことを利用者自身が DevTools と公開ソースで確認できる状態は、利用規約に署名するタイプの安心とは別物の保証です。