無料オンラインPDF圧縮

品質を保ったままPDFファイルのサイズを小さくします。結果は即座に表示され、サーバーへのアップロードは行いません。

ファイルがデバイスから送信されることはありません
ここにPDFをドロップ またはクリックして選択

対応形式: PDF · 最大100 MB

PDF圧縮について: このツールは、冗長なデータを削除し、文書構造を最適化することでPDFを圧縮します。結果はPDFの内容によって異なります, テキスト中心のPDFは10-30 %圧縮され、画像中心のPDFは20-50 %圧縮される場合があります。クライアントサイドの圧縮には、サーバーサイドのツールと比較して制限があります。

使い方

  1. 上のエリアでPDFファイルを選択またはドロップします。
  2. 「PDFを圧縮」をクリックして、ファイルをブラウザ内で処理します · アップロードは一切行いません。
  3. 最適化された PDF をすぐにダウンロードしてください。

PDFを圧縮する理由

大きな PDF ファイルは共有しにくく、アップロードも遅く、ストレージを浪費します。圧縮された PDF はより速く読み込まれ、メールで送りやすく、ディスク容量も節約できます。このツールは軽量な構造最適化を行います · オブジェクトストリームで PDF を保存し直し、孤立したリソースを削除します。典型的な削減率: テキスト主体の PDF で 5～15%。画像主体の PDF は画像自体が再エンコードされないため、削減は少なめです。

よくある質問

圧縮でPDFの品質は変わりますか？

いいえ · 画像、テキスト、ベクターグラフィックスはそのまま通過します。削減はよりコンパクトなファイル構造のみから生じ、コンテンツの再エンコードではありません。

ファイルサイズの上限は？

最大100 MBまでのPDFに対応しています。処理時間はファイルサイズとお使いのデバイスによって異なります。大きなファイルは数秒かかる場合があります。

PDFはサーバーにアップロードされますか？

いいえ。圧縮はすべてブラウザ内でローカルに行われます。PDFがデバイスから出ることはなく、プライバシーとセキュリティは完全に保たれます。

もっと圧縮できないのはなぜですか？

PDF圧縮の効果は内容の種類によって異なります。テキストのみのPDFはすでに効率的にエンコードされているため、圧縮率は低めです。画像が多いPDFはより多く圧縮できます。サーバーサイドのツールは、画像を再エンコードすることで追加の圧縮を実現できます。

暗号化されたPDFは圧縮できますか？

このツールは標準的なPDFに対応しています。暗号化されたPDFやパスワード保護されたPDFは、パスワードなしで処理することはできません。

ここで言う「圧縮」とは何か

PDF ツール界における「圧縮」という語は、かなり多くの仕事を背負っています。少なくとも三つのまったく違う操作を指しており、同じ UI 動詞を使うツールでも結果のファイルサイズはまるで違ってきます。構造最適化は、ファイルの間接オブジェクト・グラフから死んだオブジェクトを排して再構築し、小さなオブジェクトを圧縮済みのオブジェクト・ストリームへまとめ、相互参照表をバイナリ・ストリームとして書き直します。ピクセルには触れず、品質は失われません。一般的なオフィス文書での節約は 3% から 15% 程度です。画像の再エンコードは、埋め込まれた JPEG ストリームをデコードし、必要ならダウンサンプリングし、より低い品質係数で再エンコードします。写真の多い PDF では 60% 以上節約できることもありますが、操作はロスを伴います。積極的な再レンダリングは、選んだ DPI で各ページをラスタライズし、ラスタを JPEG として埋め込み直します。これは商用ツールにおける「最大圧縮」プリセットが優しいラベルの下でやっていることであり、出力は実質「PDF の殻に入った画像の山」です。

本ツールは最初の種類の圧縮しか行いません。これは意図的な選択です。構造最適化は可逆で、速く、ブラウザ内で動きサーバとの往復もなく、元の PDF が保証していた性質をすべて維持します(テキストは選択可能なまま、ベクター画像は鮮明なまま、アクセシビリティ・タグは付いたまま、フォーム・フィールドも動作したまま)。画像の再エンコードやラスタライズは特定の状況では有用ですが、忠実性をサイズと交換することになり、巨大な JavaScript コーデック群か、本ツールが意図的に持たないサーバ側のレンダリング・スタックが必要になります。したがって誠実な言い方はこうです。本ツールはテキスト中心の PDF を常にはっきり小さくしますが、画像中心の PDF はわずかにしか小さくしません。高解像度スキャンのポートフォリオで激しいサイズ削減が必要なら、求めるものは別のツールです。

PDF 内圧縮の小史

1993 年の初代 PDF Reference の段階で、すでに圧縮の主力は FlateDecode でした。gzip、PNG、そして zip フォーマット全般を駆動するのと同じ deflate アルゴリズムです。Adobe が deflate を選んだのは、ちょうど Phil Katz の PKZIP の仕事を通じてパブリック・ドメインに入ったばかりで、PDF の内部辞書やコンテンツ・ストリームのような構造化テキスト上でおおむね 2 対 1 の圧縮率を出せたからでした。やがて画像専用の三つのフィルタが FlateDecode の隣に加わります。DCTDecode(JPEG)は PDF 1.0 から写真を埋め込む標準的な方法でしたし、CCITTFaxDecode(1980 年代の Group 3 / Group 4 ファクシミリ圧縮アルゴリズム)は白黒スキャン文書を扱いました。LZWDecode は短期間 FlateDecode と争いましたが、1990 年代の Unisys 社の LZW 特許紛争を受けて PDF 1.4 で非推奨となります。

非画像圧縮にとって最も大きな変化は、2003 年の PDF 1.5 で訪れました。オブジェクト・ストリームと相互参照ストリームです。それ以前、PDF 内のすべての間接オブジェクトはファイル本体の最上位に短いオブジェクト・ヘッダ付きで現れる必要があり、各オブジェクトはファイル末尾の平坦な ASCII 相互参照表に記録されていました。両者を合わせるとオブジェクト 1 個あたり約 30 バイトのオーバーヘッドになり、千個ほどのオブジェクトを含む中程度に複雑な文書では約 30 KB ぶんが構造的なムダとして消えていました。PDF 1.5 は二つの補完的な仕組みを導入します。オブジェクト・ストリームは小さなオブジェクトをひとつの deflate ストリームに集めて圧縮し、相互参照ストリームは人間可読の xref 表を圧縮済みのバイナリ版で置き換えます。両者は組み合わせて、忠実性に何の代償も支払わずに PDF サイズから常時 10% から 15% を削ぎ落とします。

画像圧縮フィルタ群はあと二回拡張されました。PDF 1.4(2001)は二値画像向けの高圧縮率の JBIG2Decode を加え、PDF 1.5(2003)は JPEG 2000 ウェーブレット圧縮の JPXDecode を加えました。これら二つが PDF 仕様における画像圧縮の高水位線で、その後は何も追加されていません。AVIF や HEIC、JPEG XL のような現代のコーデックの研究は続いていますが、これらのいずれも現行の ISO 32000-2 では認められていません。つまり PDF における圧縮の選択肢は 20 年以上凍結されています。これは構造的な書き直し処理が今でも意味を持つ理由の一つでもあります。野にある PDF はみな今もなお 2003 年代のフォーマットの殻の中にあり、野にある PDF はみな今もなお、その殻の下できれいに再シリアライズし直してもらう余地を残しているのです。

本ツールが機械的に何をしているか

ブラウザ側で走る圧縮は、PDF を三つの決定論的なパスに通します。すべて pdf-lib が実行します。第一に、ファイルの相互参照表を読み、各間接オブジェクトをメモリ上のモデルとして解析します。破損したオブジェクトや参照されていないオブジェクトはここで記録されます。第二に、最適化パスが文書カタログから始まりオブジェクト・グラフを歩き、推移的に到達できないものをすべて破棄します。PDF はその一生で孤児オブジェクトを溜め込みがちで、特に Acrobat 内で繰り返し編集されたり、古い版を消さないままに新しい版を末尾追加していくインクリメンタル・セーブを経たりするとそれが顕著になります。この段階だけでも実際の節約は、新しく作られたばかりの PDF では 0%、何年も繰り返し開いて再保存されてきた PDF では 20% を超えるところまで出ます。

第三に、残ったオブジェクトを PDF 1.5 の機能を使って書き出します。小さなオブジェクトは圧縮済みオブジェクト・ストリームに集められ、相互参照表は ASCII テキストではなく圧縮済みバイナリ・ストリームとして出力されます。入力時点ですでに圧縮済みだったストリーム(FlateDecode 符号化されたコンテンツ・ストリーム、埋め込まれた JPEG)は、そのまま素通りでコピーされます。二重圧縮はサイズの節約にもならず、微妙なバグを混ぜ込みかねないので試みません。出力はバイト単位では入力と違いますが、視覚的にもテキスト的にも構造的にも完全に同じです。各ページは同じように描画され、各単語は同じ位置で選択でき、各注釈は元の場所に居続け、各フォーム・フィールドは同じ名前を保ちます。圧縮後に表示される「削減率」は、(入力サイズ から 出力サイズ を引き)入力サイズで割って計算されます。

なぜ画像中心の PDF はほとんど縮まないのか

圧縮目的で PDF をアップロードした多くのユーザーは、20 MB の写真ポートフォリオが 19.4 MB になって戻ってくると驚きます。理由は、典型的な写真系 PDF のバイトは構造の殻にあるのではなく、画像コンテンツ・ストリームの中にあるからです。PDF として保存された高解像度スキャンは 95% 以上が画像ストリームのバイトで占められ、構造的なオーバーヘッド(カタログ、ページツリー、xref、フォント・メタデータ)は、長い文書であっても合計で数百キロバイトに収まります。本ツールは画像ストリームを復号も再エンコードもしないので、それらのバイトの絶対サイズは動きません。

50 MB の画像中心 PDF を、現実問題として 10 MB を切る大きさに落とす必要があるユーザーには三つの選択肢があり、いずれも本ツールの現在のアーキテクチャ内では実装できません。最もきれいな手順は、一歩戻ることです。元画像を取り出し、無料画像圧縮オンラインに通してから、画像をPDFに変換 で組み立て直します。二つ目の選択肢は、Adobe Acrobat の PDF Optimizer や Apple の「プレビュー」の「ファイルサイズを縮小」Quartz フィルタのように、画像の再エンコードを内蔵したデスクトップ・ツールを使うことです。三つ目は、商用のサーバ側サービスで「高圧縮」モードがクラウド上でまさに同じことを行うものを使うことです。攻めの強さとプライバシーの間にあるこのトレードオフは根本的なものです。真に攻めた画像圧縮パイプラインには、本ツールが意図的に同梱しない数メガバイトの JavaScript コーデック群が必要か、あるいはプライバシーの約束を手放すことになるサーバが必要です。本ツールは設計空間の「保守的だが私的」な角に居続けます。

構造的なパスが本当に役立つ実用ケース

他の PDF 機能との相互作用

ブラウザだけで圧縮するのか、クラウドに頼るのか

Google の検索結果で上位を占めるクラウド型の PDF 圧縮サービス(Smallpdf、ILovePDF、PDF24 の Web アプリ、Adobe Acrobat Online、Sejda の無料プラン)はみな、ソース PDF を自社サーバへアップロードし、そこで圧縮を行い、結果の小さなファイルをダウンロードとして返します。各社のプライバシー・ポリシーは、アップロードされたファイルは数時間以内に削除されると述べていますが、それでもファイルは事業者のネットワークを通過し、処理ウィンドウの間そのディスク上に存在し、不正利用検知のために事業者が保持するあらゆるログを通り抜けます。代わりに彼らが提供するのは、攻めた画像再エンコードやラスタライズのオプションへのアクセスで、これはブラウザ専用のツールが追加で数メガバイトの JavaScript を抱え込まずに匹敵することはできません。

本ツールはアップロードしません。お手元の PDF は標準 File API を通じてブラウザのタブに読み込まれ、同じタブの中で pdf-lib ライブラリにより解析・再書き出しされ、標準のダウンロード API を通じてお手元のディスクへ書き戻されます。圧縮中の唯一のネットワーク通信は、ページを初めて開いた瞬間に pdf-lib 自身を CDN から一度だけ取得することだけです。これは検証可能です。ブラウザの開発者ツールを「ネットワーク」タブで開き、圧縮を一度走らせて、ファイルの内容を運ぶリクエストが一切発火しないことを確認してください。何らかの形で秘密性のあるもの(HIPAA、GDPR、弁護士・依頼者間の秘匿特権、秘密保持義務に係るもの)はブラウザ内で圧縮するのが最良です。50 MB を 5 MB まで落とす必要のある写真ベースのものは、データ取扱条件を読んで明示的に選んだサーバ側ツールに任せるか、画像圧縮ツールと画像から PDF を組み合わせて、明示的な「復号 - 再エンコード - 再組み立て」サイクルを回すのが向いています。

さらによくある質問

結局どれくらい小さくなるのか?

構造的なパスでは、テキスト中心の業務 PDF は通常 5% から 15% 縮みます。何度も編集されたファイルが分布のロング・テールを作り、そこでは 20% から 30% に達することもあります。画像中心の PDF は数 % しか縮みません。画像のバイト自体が再エンコードされないためです。PDF Association の 2018 年の 12,000 件の EU 政府 PDF ベンチマークでは、生成元のアプリケーション別に平均 5% 〜 18% の削減が報告され、pdf-lib の 2021 年の 500 件の混在ビジネス文書ベンチマークでは、平均 8.4%、中央値 7.1% でした。それ以上を期待している方は、暗に画像再エンコードを求めているのであって、それは別の操作です。

なぜ Adobe Acrobat の圧縮と結果サイズが違うのか?

Adobe Acrobat の PDF Optimizer は、構造的な書き直しの上に画像クラスごとのダウンサンプリング・オプションを重ねています。既定では 300 DPI 超のカラー画像を 150 DPI へ、グレースケールを 100 DPI へ、モノクロを 600 DPI へとダウンサンプリングし、いずれもユーザーが選んだ JPEG 品質でロスありの再エンコードを行います。したがって既定設定の Acrobat の出力は、画像中心の文書では必ず本ツールより小さくなりますが、入力とは目で見て分かるほど違ってもいます。写真はわずかに柔らかく、線画は再ラスタライズされます。本ツールはピクセル単位で同一の文書を作りますが、Acrobat の PDF Optimizer は別の文書を作ります。

暗号化やパスワード保護の PDF も圧縮できるか?

直接はできません。開封パスワード付きの PDF はパスワードが提供されるまでパースできず、pdf-lib はどの操作でも暗号化 PDF をサポートしていません。流れとしては、まず 無料オンラインPDFロック解除 ツールでパスワードを外し、解錠済みのコピーをここで圧縮し、必要なら 無料PDFパスワード保護オンライン ツールで再度保護を掛け直します。圧縮後のコピーは、元の署名済み・暗号化済みの文書とは別の文書ですので、署名の有効性やアクセス制御はこの往復で保たれません。

タグ付き PDF のアクセシビリティは保たれるか?

保たれます。スクリーンリーダー(JAWS、NVDA、VoiceOver)の挙動を司る構造ツリーは、文書カタログから到達できる間接オブジェクトとして保管されており、最適化パスは到達可能なすべてのオブジェクトを保持します。正しくタグ付けされた PDF は、圧縮後もなお正しくタグ付けされており、見出し階層もリスト構造も図の代替テキストも読み上げ順序もすべて同じです。これは「構造のみのアプローチ」が正しい設計選択である理由の一つでもあります。商用ツール内のもっと攻めた画像再エンコード処理は構造ツリーを静かに壊してしまうことがあり、ラスタライズ処理は必ず破壊します。

大きなスキャン物に対して本当に積極的な圧縮をかけたい場合は?

大きなスキャン PDF に対する Absolutool 内で最も有効なネイティブ・フローは、三つのツールを組み合わせることです。無料PDF画像抽出ツールでページを JPEG として取り出し、無料画像圧縮オンラインで選んだ品質にダウンサンプリングして再エンコードし、画像をPDFに変換 で組み立て直します。各工程に明示的な品質管理を持つ予測可能な出力が得られ、すべてブラウザ内で完結し、どの段階でもアップロードは発生しません。商用サイトで「最大圧縮」を 1 クリックする以上の手間ではありますが、そこで得られるのは、予測可能性とプライバシーを大切にするユーザーに奉仕する、組み合わせ可能で正面から作られた道具という、本サイトのより大きな哲学そのものです。

関連ツール

PDF結合

複数のPDFを1つのファイルに結合します。

PDF分割

PDFをページ単位または範囲で分割します。

画像圧縮

画像を最大80 %まで小さくします。