# parse-video turns a share link into the media URLs behind it

> parse-video is a Go service and command line tool that takes a share link from a short video platform and returns the direct media addresses, with a per platform parser, an HTTP mode with a web front end, a JSON output and a Docker image. It supports the video platforms and image collections listed in the README, and its Douyin path can optionally use a cookie you supply yourself.

**wujunwei928/parse-video** — Golang短视频去水印：抖音,皮皮虾,火山,微视,最右,快手,全民小视频,皮皮搞笑,西瓜视频,虎牙,梨视频,acfun,好看视频...

- Repository: https://github.com/wujunwei928/parse-video
- Stars: 1,075 · Forks: 284
- Language: Go
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/wujunwei928-parse-video

## It resolves the link, it does not host the content

The project is described in its own README as a Go tool for removing watermarks from short videos, with support for 22 video platforms and four image collection platforms, and a note that the current version covers video while image collections are supported separately.

What the code actually returns is a set of URLs. The JSON response shape in the README is the clearest description of the contract.

```json
{
  "author": {
    "uid": "uid",
    "name": "name",
    "avatar": "https://xxx"
  },
  "title": "记录美好生活#峡谷天花板",
  "video_url": "https://xxx",
  "music_url": "https://yyy",
  "cover_url": "https://zzz",
  "images": [],
  "image_live_photos": []
}
```

The video_url field is the address of the video without the platform watermark, and the music_url and cover_url are the soundtrack and the thumbnail. The images array carries the addresses for an image collection, and image_live_photos carries the live photo variant of those images. There is a warning attached to the field table, that apart from the video address the other fields may be empty.

So the tool is a resolver. It takes a share link, fetches the share page, extracts the media addresses, and hands them back. The README says the parser does not call third party download or parse services, which is a meaningful property for a deployment that handles links the operator may not want sent elsewhere.

The README also advises using the app share link where possible, and notes that the desktop web version has not been tested.

## One parser per platform, and the list is the contract

The supported platform table is the first thing in the README and it is long. For image collections the listed platforms are Douyin, Kuaishou, Xiaohongshu, Pipixia and Weibo, and a separate table covers the LivePhoto variant with Xiaohongshu marked as supported.

The video table covers a mix of Chinese short video platforms and the larger video sites, including Xiaohongshu, Pipixia, Douyin, Huoshan, Pipigagui, Kuaishou, Weishi, Xigua, Zuiyou, Li, Duxiaoshi, Doupai, Weibo, Lvzhou, Quanmin K, 6jianfang, Meipai, Xinpianchang, Haokan, Huya, AcFun, CCTV, Bilibili, Tencent Video and Sohu Video.

The architecture follows from that list. The repository has a parser/ directory, and the mechanism is a family of per platform implementations that recognise a share link, fetch what is needed, and return a common record. The dependency list explains how the fetching is done, with resty as the HTTP and REST client, goquery for jQuery style HTML parsing, and gjson to pull a value out of a JSON document in one line.

That combination, an HTML parser and a JSON path extractor, is the signature of a scraper that handles both kinds of page. Some platforms embed the media address in the HTML of the share page, and some return a JSON payload that has to be picked apart.

The consequence for a user is that support is per platform and per page layout, and a platform that changes its share page can break its parser without anything in the code changing. The README's note that the desktop web version was not tested is the same class of warning, and it applies to every entry in the table rather than to one platform.

## serve mode is a small service with a web front end

The default subcommand is serve, which starts an HTTP parsing service, and the README documents it as the default command so that a bare invocation does the right thing.

```bash
go run main.go

go run main.go serve --port 9090
```

The service has a front end. The README says to visit http://127.0.0.1:8080/ to see the pages, and gives the API endpoint for the JSON result.

```bash
curl 'http://127.0.0.1:8080/video/share/url/parse?url=视频分享链接' | jq
```

Authentication is basic auth, and it is configured with two environment variables rather than a flag, which is the right shape for a service that might be exposed.

```bash
export PARSE_VIDEO_USERNAME=basic_auth_username
export PARSE_VIDEO_PASSWORD=basic_auth_password
go run main.go serve
```

The proxy is handled the same way. All parsing requests go through the proxy if one is set, using PARSE_VIDEO_PROXY, and the README shows both an unauthenticated and an authenticated form, with the credentials embedded in the URL.

In the repository, the service side is in api/ and cmd/, the templates and static assets are in templates/ and static/, and the shared helpers are in utils/. The library entry point is main.go at the root, and the project also has docs/, an AGENTS.md and a CLAUDE.md, plus an .air.toml for live reload during development.

## The parse and id subcommands are the scripting surface

Beyond the service, there are two commands that do the actual work, and the README shows both in enough detail to use without reading the source.

The parse command takes a share link, and it is flexible about how you give it to the tool.

```bash
go run main.go parse "https://v.douyin.com/xxxxx"

go run main.go parse "7.87 Pjm:/ 复制打开抖音 https://v.douyin.com/xxxxx"

go run main.go parse "链接1" "链接2" "链接3"

go run main.go parse --file links.txt

echo "https://v.douyin.com/xxxxx" | go run main.go parse -f -
```

The second example is the one worth noting, because pasting the whole share text from the app is what a person actually does, and the parser will find the link inside it.

The id command takes the platform and the video id instead of a link, and the --source flag is mandatory, with the available values visible from the error message when a parse fails.

```bash
go run main.go id --source douyin "视频ID"
```

Both commands share the same output options. The --format flag chooses between text, which is the default, and json. The --download or -d flag downloads the media files that were resolved, which means the video, the image collection, the cover and the music, and --output-dir or -o sets where they go, with the current directory as the default. The parse command adds --file or -f, which takes a file of links, one per line, with a dash meaning standard input.

There is also a version command, and the compiled binary is called parse-video, with go run main.go standing in for it during development.

## The Douyin cookie fallback is the part to read carefully

One platform needs more than a share page, and the README explains the mechanism and the risk in some detail.

When a Douyin share page does not embed the work details, the parser will request Douyin's official web details interface. The deployer can configure their own account's complete cookie request header to enable that fallback path, through the PARSE_VIDEO_DOUYIN_COOKIE environment variable.

```bash
export PARSE_VIDEO_DOUYIN_COOKIE='部署者自有的完整 Cookie 请求头'
go run main.go parse "抖音分享链接"
```

The README is explicit that this value is a sensitive credential and should not be committed to the repository or taken from someone else. It also sets the boundary of the feature: when it is not set, parsing of pages that already contain the details is unaffected, and only the requests that need the fallback path return an explicit configuration error rather than failing silently. That is a well behaved design, because a misconfigured fallback is reported instead of producing a wrong answer.

The last point in that section is worth repeating as a property of the whole project, that the parser does not call third party download or parse services. Every request goes out from your own deployment, through your own proxy if you configure one, which means the operator can see and control every outbound request.

## A small Go codebase, and a scratch container

The implementation is a compact Go module. The go.mod requires Go 1.24.0, and the direct dependencies are goquery 1.10.3, gin 1.11.0, resty 2.16.5, cobra 1.9.1 and gjson 1.18.0, with golang.org/x/net and golang.org/x/time alongside. Cobra is the command line framework, gin is the web framework for the service, and the other three are the scraping tools.

The Dockerfile shows a two stage build ending in a scratch image.

```dockerfile
FROM golang:alpine AS builder
ENV CGO_ENABLED 0
ENV GOPROXY https://goproxy.cn,direct
...
RUN go build -ldflags="-s -w" -o /app/main ./main.go

FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
COPY --from=builder /usr/share/zoneinfo/Asia/Shanghai /usr/share/zoneinfo/Asia/Shanghai
ENV TZ Asia/Shanghai
```

The final image has no shell and no package manager: just the binary, the CA certificate bundle, the time zone data and the templates directory, with port 8080 exposed.

The images are published as wujunwei928/parse-video, and the README shows the run commands for the default port, a custom port with the -port argument passed to the container, basic auth through the two environment variables, and the proxy through PARSE_VIDEO_PROXY.

```bash
docker run -d -p 8080:8080 wujunwei928/parse-video
```

On the licensing and maintenance side, the project is MIT licensed with the file at the repository root. The listed releases are v0.0.2 from 2026-04-18 and v0.0.1 from 2024-09-22, so the version numbers are still pre 1.0, and the last push was on 2026-08-21.

## Conclusion

parse-video fits a developer who needs the direct media address behind a share link, for example to feed a downloader, a test fixture or an archiving script, and who would rather run the parser themselves than call a hosted service. It is the wrong tool if you need the content of a platform rather than its address, and it is the wrong tool for a workflow that depends on the share page layout staying the same. Verify first whether the platform you need has a parser in the current tree, since the supported set is a list in the README rather than a guarantee, and keep any cookie you configure out of your repository.

## FAQ

### How do I run parse-video?

During development you use go run main.go, which starts the serve subcommand by default and listens on port 8080, and go run main.go serve --port 9090 starts it on a different port. The compiled binary is called parse-video, and there is also a Docker image published as wujunwei928/parse-video.

### Which platforms does parse-video support?

The README states support for 22 video platforms and four image collection platforms, and the tables list services including Douyin, Kuaishou, Xiaohongshu, Pipixia, Weibo, Bilibili, AcFun, Huya, Tencent Video and Sohu Video among others. The set is a list in the README rather than a guarantee for any one platform.

### What does parse-video return?

A JSON object with the author details, a title, and the video_url, music_url and cover_url addresses, plus images and image_live_photos arrays for image collections. The README notes that apart from the video address the other fields may be empty.

### What is the PARSE_VIDEO_DOUYIN_COOKIE variable for?

It is an optional fallback for Douyin share pages that do not embed the work details, in which case the parser requests Douyin's official web details interface. The value is the deployer's own full cookie header, the README warns that it is a sensitive credential that should not be committed, and without it only the requests needing that path return a configuration error.

### How do I protect the parse-video service?

You can enable basic auth with the PARSE_VIDEO_USERNAME and PARSE_VIDEO_PASSWORD environment variables, and you can send all parsing requests through a proxy with PARSE_VIDEO_PROXY, which the README shows in both unauthenticated and authenticated forms. The parser does not call third party download or parse services.

## Sources

- [Issues](https://github.com/wujunwei928/parse-video/issues)
- [License: MIT](https://github.com/wujunwei928/parse-video/blob/main/LICENSE)
- [README](https://github.com/wujunwei928/parse-video/blob/main/README.md)
- [Releases](https://github.com/wujunwei928/parse-video/releases)
- [wujunwei928/parse-video on GitHub](https://github.com/wujunwei928/parse-video)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wujunwei928-parse-video