# Converter类网站还有机会吗？

URL: https://caijiao.org/posts/93
Source: docs/posts/93.md
Description: 我做过一个转换站死在服务器账单上。TinyWow 敢承诺文件 1 小时删除是因为不落盘；ffmpeg 编译成 WebAssembly 后转码不再需要服务器。

我自己做过一个格式转换站，死掉了。不是没人用，是服务器账单先撑不住。

当时的实现很朴素：文件上传到服务器，服务端跑转换，结果存一段时间供下载。逻辑上没毛病，问题出在三件事上——带宽成本按文件体积线性增长，用户上传的证件和合同要我承担保管责任，还有最现实的一条：同样的功能别家免费，而且更快，因为它们在浏览器里跑。

## 我那个转换站死在服务器账单上

上面那三条里，第二条最致命。用户上传的是身份证扫描件、劳动合同、病历，一旦你要存，就得解释存多久、谁能访问、删没删干净。我写了隐私说明，但解释成本比开发成本高得多。

后来我把流量数字拿出来算了一遍：就算当时那点访问量翻十倍，广告收入也盖不住存储和带宽。这个模型从第一天起就不成立。

## TinyWow 敢承诺 1 小时删除，是因为大部分处理不落盘

TinyWow 2019 年从一个 PDF 转换器起步，现在挂了 250 多个免费工具，第三方估算月访问在 180 万到 230 万之间（2026 年上半年）。

![TinyWow 工具站首页截图](/images/2026-09/tinywow.com.png)

*TinyWow 首页把 AI Write 并进了工具矩阵，文本类任务和文件转换共用一个搜索框。*

它官网上有一句很关键的话：**上传的文件 1 小时后自动删除**，而且所有工具免注册。这句话看着是隐私承诺，其实是一句架构声明——它有能力让大部分处理不进入需要长期保管的路径。

纯客户端处理的站根本不需要这句话，因为文件压根没上传；需要这句话的站，是在告诉用户"我确实要碰你的文件，但只碰一小时"。两种架构里前者的成本低得多，而后者要承担全部合规责任。

## ffmpeg 编译成 WebAssembly 之后，成本结构变了

这几年真正改变 Converter 类站成本结构的是 [WebAssembly](/webassembly/)。音视频编解码、图片压缩、文档解析这些原本必须跑在服务端的重计算，现在能放进浏览器——ffmpeg 编译成 wasm 之后，转码这件事不再需要一台服务器。

对一个人来说这是决定性的：你不用再为峰值流量准备算力，也不用担心有人上传一个 2GB 的文件把队列堵死。用户的电脑就是你的计算资源，用的人越多，你越省钱。

10015.io 就是按这个思路做的。Fatih Telis 用 Next.js + styled-components 做了 50 多个工具，**几乎所有工具都在客户端运行，极少请求服务端**，服务器消耗接近零，所以它能靠 AdSense 的约 300 美元月收入维持下去。

## 上传这一下，是服务端绕不过去的那一秒

也不是所有转换都能塞进浏览器。超大文件、批量处理、跑几分钟的长任务，浏览器还是会崩。

真要保留服务端路径，工程上必须先把边界设死：上传体积上限、并发任务数、任务超时时间、临时文件清理周期。静态资源和下载链路交给 [nginx](/nginx/) 处理，转码任务封进 [Docker](/docker/) 容器里跑，容器挂了就重启，别让它在宿主机上留状态。

这套配置本身不复杂，复杂的是你得承认自己从此是在经营一家"有服务器的公司"——它的维护成本跟纯前端站不是一个量级，而且这个成本会一直存在。

## 2025 年它被 Jenni.ai 收购，说明这类资产的价值在哪

TinyWow 在 2025 年被 Jenni.ai 收购。这个动作说明了一件事：250 多个工具、月访问两百万、直接访问占比 47.29%、搜索占 33.83%——这个组合值钱的地方不是"工具多"，是**它已经变成了一个被记住的入口**。

直接访问接近一半，意味着就算搜索算法明天变了，它还有一半流量是算法带不走的。

我的具体建议是：别再做"另一个 PDF 转换器"，去找那些还没人做出客户端版本、或者隐私敏感度高到用户根本不敢上传的细分转换。判断方法很机械——打开竞品那个转换工具，看一眼浏览器的网络面板，如果它还把你的文件传到服务器，而你能在客户端实现同样的转换，那就是你的位置。

---

*TinyWow 工具数量与发展过程引自其官网，流量结构为第三方估算（2026 年上半年）；10015.io 技术选型与收入来自作者自述。*