把收據、證件掃描和照片變成一份 PDF——紙張大小、放置方式、邊界都由你決定，什麼都不會離開這個分頁。
檔案不會離開你的瀏覽器 — 全部在本機處理。
把圖片拖到這裡
JPG、PNG、HEIC、WebP、AVIF、GIF、BMP 都可以，也能點一下挑檔案。全部在這個分頁裡處理，不會上傳。
照片的位置資訊和相機資訊不會出現在 PDF 裡：JPEG 放進去之前會先拿掉 EXIF，PDF 本身也不帶文件資訊（作者、製作軟體或日期）。
JPEG 和 PNG 原樣放進去，JPEG 不會重新壓縮。WebP、HEIC、AVIF、GIF（只取第一格）和 BMP 會先轉成品質 90 的 JPEG；有透明的話就轉成 PNG。
HEIC 和 AVIF 會先交給瀏覽器解碼，瀏覽器不行就改用內建的解碼器，大張照片會比較慢。
不做 OCR：每一頁都是圖片，PDF 裡的字沒辦法搜尋或複製。
手機拍的收據、身分證正反面、六頁作業、一疊白板照片：這頁把它們變成一份 PDF，一張圖一頁，什麼都不上傳。丟進 JPEG、PNG、WebP、HEIC、AVIF、GIF 或 BMP，拖曳排順序，把拍歪的轉正，選紙張大小（A4、Letter、Legal、A5，或跟每張圖一樣大）、方向（自動、直式、橫式）、圖片怎麼放（等比放入、填滿裁切、原尺寸）和邊界，然後下載。
JPEG 會以它原本的壓縮 bytes 放進 PDF，不會再壓一次，畫質不會掉。放進去之前會先拿掉 EXIF 區塊，那是手機寫入相機型號、時間和 GPS 位置的地方，所以照片的拍攝地點不會跟著進到 PDF。方向是用頁面的變換矩陣處理，不是旋轉像素，所以照片擺正了也不用重新編碼。WebP、HEIC、AVIF、GIF（第一格）和 BMP 沒辦法直接嵌入，會先轉成品質 90 的 JPEG；PNG 則是從解碼後的像素無損嵌入。
輸出建立時沒有 Document Information Dictionary——沒有作者、Producer、建立日期或工具名稱，而且如上所說，也沒有照片的 EXIF 和 GPS。寫完之後會重新載入一次，核對頁數等於圖片張數；對不上就是錯誤，不是下載。另一個它不會帶的是文字：這份 PDF 是一頁頁的圖，不是可搜尋的文字，因為這頁不做 OCR。要搜尋或複製文字，那是另一個步驟。
HEIC 和 AVIF 在瀏覽器自己支援時由瀏覽器解碼，不支援時用內附的解碼器，大照片會明顯慢一些。其他部分就只是 File API 和這個分頁裡的 JavaScript：把網路關掉，PDF 照樣做得出來——證件、就診表單、任何拍到地址的東西，要的正是這個性質。
不會。圖片用 File API 讀進來，PDF 在這個分頁裡用 JavaScript 組出來，下載是瀏覽器在記憶體裡生的檔案。這頁背後沒有 API，所以證件掃描或拍下來的就診表單，除了你自己的硬碟之外沒地方可去。
不會。JPEG 的 EXIF 區段——相機型號、時間戳記、GPS 座標——會在嵌入前以 bytes 層級拿掉，不碰圖像資料。PDF 本身也不寫作者、Producer 和日期。方向靠圖片擺在頁面上的方式保留，所以方向標籤沒了，照片還是正的。
JPEG 和 PNG 不會。JPEG 的壓縮 bytes 原封不動進 PDF，沒有重新編碼；PNG 從像素無損嵌入。WebP、HEIC、AVIF、GIF 和 BMP 不能直接嵌入，會先轉成品質 90 的 JPEG——損失很小，通常看不出來。配合紙張的縮放是 PDF 閱讀器顯示時做的，不會重新取樣像素。
可以。HEIC（和 AVIF）在瀏覽器裡解碼：瀏覽器原生支援就直接解，不支援就用內附的解碼器，大照片會比較慢。解出來的圖片存成品質 90 的 JPEG 再放上頁面。兩種情況都不會送出任何東西。
不能。每一頁就是一張圖，跟照片一模一樣；沒有跑 OCR，所以 PDF 閱讀器看到的是圖片而不是文字。只是要交出去的收據和表單，這樣就夠了。需要可搜尋的 PDF，事後再拿輸出去跑 OCR 工具。
把做好的 PDF 跟其他 PDF 合成一份，順序自己排。
把 PDF 拆成幾份、抽出幾頁，或刪掉不要的頁面。
HEIC、WebP、AVIF 只想轉成 JPG 或 PNG 圖片檔的話用這個。
先把大張照片壓小，PDF 就不會太肥。
看看手上的 PDF 帶了哪些作者、日期資訊，再把它清掉。