纯前端 PNG/JPG 转 PDF 工具(无需服务器,源码分享)

纯前端 PNG/JPG 转 PDF 工具(无需服务器,源码分享)

纯前端 PNG/JPG 转 PDF 工具(无需服务器,源码分享)

✨ 一个完全运行在浏览器中的图片转 PDF 工具,不依赖后端、不上传文件、保护隐私,支持拖拽、排序、预览、批量导出,代码开源,一键部署!

🌐 在线演示

👉 https://longsongline.github.io/png-to-pdf/

在这里插入图片描述

打开即可使用,无需注册、无需登录,所有处理都在你的浏览器中完成!


📦 功能特性

  • 纯前端实现:基于 jsPDF + FileReader,无任何服务端依赖
  • 隐私安全:图片不会上传到任何服务器,全程本地处理
  • 多格式支持:PNG、JPG、BMP、TIFF、SVG(自动转 PNG)
  • 灵活输出
    • 合并为单个 PDF(每张图一页)
    • 每张图生成独立 PDF
  • 交互友好
    • 拖拽上传 / 点击选择
    • 图片预览(带缩放)
    • 手动排序 / 按文件名排序
    • 删除选中 / 清空全部
    • 文件大小显示、操作日志提示

💻 使用方法

  1. 打开 在线工具
  2. 拖入或点击选择多张图片
  3. 调整顺序(可选)
  4. 选择输出模式
  5. 点击「导出 PDF」即可下载!
⚠️ 首次加载会从 CDN 加载 jsPDF 库(约 100KB),请确保网络畅通。

🧩 技术实现

  • 核心库jsPDF v2.5.1
  • 编码规范:UTF-8(避免中文乱码)
  • 兼容性:现代浏览器(Chrome / Edge / Firefox / Safari)

关键逻辑:

  • 使用 FileReader 读取本地文件为 DataURL
  • SVG 自动转为 PNG 再嵌入 PDF
  • 利用 addPage() 实现多页布局
  • 响应式 UI + 拖拽排序 + 图片预览模态框

📂 源码 & 部署

🔗 GitHub 仓库

🚀 如何部署自己的版本?

  1. Fork 本仓库
  2. 进入仓库 → Settings → Pages
  3. 设置 Source 为 main 分支 + / (root)
  4. 保存,等待 1 分钟
  5. 访问:https://你的用户名.github.io/png-to-pdf/
💡 完全免费!GitHub Pages 自动提供 HTTPS。

📝 注意事项

  • 中文乱码问题
    请确保 index.htmlUTF-8 无 BOM 编码保存(推荐直接在 GitHub 网页编辑器修改)。
  • 大图处理慢
    浏览器内存有限,建议单图不超过 10MB。
  • PDF 分辨率
    默认按 A4 尺寸居中缩放,保持原始比例。

❤️ 开源协议

本项目为 MIT 协议,欢迎 Fork、Star、提 PR!

如果你觉得有用,欢迎点赞 👍 或分享给需要的朋友!


作者:longsongline
更新时间:2026年3月
关键词:前端工具、图片转PDF、纯前端、jsPDF、GitHub Pages、无后端

Read more

规范驱动编程系列——亚马逊AI编程工具Kiro工具实测6——前端验证及调整

接下来看一下前端的代码输出。 前端结构 前端生成的位置经过指令指示,要求放到已有的工具模块下,生成的位置是准确的,如下: API 前后端交互的 API,AI 并没有参照项目现有情况,根据自行生成了一套跟后端自己设计的接口一致的 API,如下: import{COMMON_METHOD}from'@/constant/common'import request from'@/config/axios'import type { LifeSettingsRequest, LifeSettingsResponse, ApiResponse }from'../view/lifeCalendar/types'const moduleName ='tool'// 生命日历设置APIexportconst lifeCalendarSettingApi ={/** * 获取用户生命日历设置 */getSettings(): Promise&

【架构】前端 pnpm workspace详解

前端 pnpm workspace 架构详解 一篇帮你搞懂 pnpm workspace 的实战向教程,从「为啥要用」到「怎么配」全给你捋清楚;每个知识点都会讲清是什么、为什么、怎么用、注意啥,方便你系统学习、随时查阅、直接落地。 一、先聊聊:我们到底遇到了啥问题? 做前端久了,多包、monorepo、组件库联调这些事一多,就会踩到一堆具体又磨人的坑。下面把这些痛点拆开说:具体表现 → 典型场景 → 对你有啥影响。搞清楚这些,后面再看 pnpm workspace 解决啥就一目了然。 1.1 node_modules 膨胀,磁盘和时间都遭殃 具体表现:用 npm 搞 monorepo 时,根目录一个

0. 总纲|Java Web 自研框架 18 年Java架构决策复盘

0. 总纲|Java Web 自研框架 18 年Java架构决策复盘

深耕政务信息化 20 年,自研 Java Web 框架支撑省级新农保、全国跨省医保结算等核心民生系统,稳定运行 18 年。 本系列不讲空泛理论,只复盘真实生产环境下的架构决策、踩坑经历、落地方案,不求优雅,但求能跑、能扛、能维护。 在长期维护政务系统的过程中,我逐渐形成一套轻量、稳定、无侵入、可长期演进的架构思路。 这套框架没有依赖流行全家桶,而是围绕业务痛点一点点打磨,最终支撑了海量高并发、高可靠的民生业务。 本系列将从以下 10 个核心决策展开: 1. 放弃 Spring,手写轻量 IOC 容器 2. 注解路由 + 参数路由,实现新老代码平滑迁移 3. 统一入参解析,前后端彻底解耦 4. CGLIB + 责任链实现轻量 AOP,搞定事务、日志、

Dify Web 前端二次开发(隐藏探索功能 + 替换 Logo)

核心修改内容 1. 隐藏导航栏「探索」功能(图标 + 文字按钮); 2. 将默认 Dify Logo 替换为自定义 FDAI Logo(PNG 格式)。 (一)隐藏「探索」功能完整过程 1. 定位目标组件 探索功能对应的组件文件路径:web/app/components/header/explore-nav/index.tsx(组件名:ExploreNav),该组件被嵌套在 Header 组件中渲染,无需修改布局文件 app/(commonlayout)/layout.tsx。 2. 首次尝试:仅删除图标(未彻底隐藏) * 操作:删除组件内图标渲染代码 { activated ? <RiPlanetFill />