Thunder-HTTPS turns thunder:// and ed2k:// links into plain HTTP, and its licence bans competition use

Five link formats, one desktop window

Thunder-HTTPS is a download link conversion tool that supports decoding and conversion of multiple protocols, built with Electron and Vue 3 for a modern interface.

The protocol list is the substance of the project. Thunder links, with the thunder:// prefix, are Base64 encoded and wrapped in AA and ZZ markers. The QQ download client links, with the qqdl:// prefix, are Base64 encoded. FlashGet links, with the flashget:// prefix, are Base64 with FLASHGET markers. eDonkey links, with the ed2k:// prefix, are parsed as standard protocol fields. And magnet links, with the magnet:?xt= prefix, are parsed as URI parameters.

The reason these formats need a converter at all is that they are for a specific download client, not for a browser. A thunder:// link encodes a URL inside Base64 with wrapper characters that the originating client knows how to strip, and no browser will do that for you. The tool is therefore a translator between a client specific envelope and a plain HTTP or HTTPS address that anything can open.

The user flow is short, and the documentation is explicit about it: copy a download link, paste it into the input box with a paste shortcut, click the convert button, and then handle the result, either copying it to the clipboard, opening it in the browser to verify it, or saving the results to a file.

Two details make it usable rather than a curiosity. The output is copied to the clipboard automatically, and there is a batch save option, so a list of links can be converted and exported in one pass. The interface is bilingual, Chinese and English, through the vue-i18n library.

The conversion engine is isolated under src/core

The project structure is the clearest description of the architecture, and it separates the desktop shell from the logic that actually decodes links.

The Electron main process lives in src/main, with index.js as the entry point and ipc.js handling inter process communication. A preload script sits in src/preload, and the Vue renderer, with components, composable functions, internationalisation and styles, is in src/renderer.

The part worth reading is src/core. It contains the core conversion engine, with a protocols/ directory holding the decoders for each format and a utils/ directory for helper functions. That separation is the design decision in this repository: the decoders are plain JavaScript modules with no dependency on Electron or on Vue, so they can be tested, and reused, without a window on screen.

Around that sit the build files. There is a build/ directory for resources such as icons, a dist/ directory for build output, installer.nsi as the NSIS installer script, electron-builder.yml for the packaging configuration, package.json, and set-icon.js as a script that sets the application icon.

The stack table names the technology behind each layer: Vue 3 as the frontend framework, Electron 33 or newer as the desktop framework, Vite as the build tool, vue-i18n for internationalisation, electron-builder for packaging, rcedit for icon setup, and NSIS for installer packaging.

The renderer and main process are strictly separated with a preload bridge between them, which is the standard Electron pattern and the one that keeps a Vue frontend from having direct Node access.

Development needs Node 18 and a two process dev script

The build instructions are short, and the one interesting part is the development script.

The prerequisites are Node.js 18 or newer, npm or yarn, and Git. Getting the source is the usual two commands:

git clone https://github.com/helloworldpxy/thunder-https.git
cd thunder-https

Then the dependencies and the dev server:

# Install dependencies (node_modules is not in repo, install manually)
npm install

# Start dev server
npm run dev

The note in the documentation is worth reading: node_modules and dist directories are excluded via .gitignore and are not included in the repository, so the install step is not optional and you cannot skip it and run the app from a fresh clone.

What the dev script actually does is visible in the package manifest. The dev entry runs the Vite dev server and Electron at the same time, waiting for the Vite server to be reachable on port 5173 before starting Electron. That is the standard shape for an Electron plus Vue setup: the renderer is served by Vite with hot reload, and the main process opens a window pointed at the dev server rather than at the bundled files.

The production scripts follow the same split. A plain build runs vite build, while the Electron packaging script runs the Vite build and then electron-builder, and the Windows variant adds a --dir flag, which produces an unpacked directory rather than an installer, and then runs the icon script.

So the dev loop is one command, and the packaging path is a different command, and the difference between an unpacked build and an installed one is a flag in the script.

Windows packaging goes through electron-builder, rcedit and NSIS

The two build commands in the documentation are the ones you will actually run on Windows:

# Build for Windows
npm run electron:build:win

# Generate installer and portable version
node set-icon.js

The first builds the Windows version. The second generates the installer and the portable version by running the icon setup script.

The icon step is not decoration. On Windows, an executable carries its own icon and version metadata as resources inside the binary, and electron-builder does not always produce the right thing, so the project depends on rcedit to patch it afterwards. The set-icon.js script drives that, and to-ico is in the dependency list as well, which is the usual way to turn a PNG into the multi resolution ICO that Windows expects.

The packaging configuration itself lives in electron-builder.yml, and the installer is an NSIS script, installer.nsi, which is the NSIS based installer generator that electron-builder uses on Windows. The two artefact types the project ships, an installer executable and a portable archive, come from that pairing.

The user facing documentation explains the two distribution shapes. The installer is the recommended route: download the Thunder HTTPS Setup 2.0.0.exe, run it, and a desktop shortcut is created. The portable version is an archive you extract to any directory and run, with the instruction to keep all files in the folder intact because the executable expects its neighbours.

That last point is the operational difference between the two. The installer manages the files, the portable version makes you responsible for them, and the second is the one that breaks when someone tidies up the folder.

The licence is non commercial and it names competitions

This is the part to read before anything else, because it is narrower than a typical open source licence.

The project is licensed under the PolyForm Noncommercial License 1.0.0, and the package manifest records the same identifier, PolyForm-Noncommercial-1.0.0. The copyright notice adds a clause that goes beyond the standard licence text: unauthorised use in any competition, contest or hackathon is prohibited without written authorisation from the author. The author is listed as HelloWorld05, with the copyright dated 2025.

Two consequences follow, and they are different in kind.

The non commercial term means the tool cannot ship inside a commercial product. That covers the obvious case of a download manager you sell, and it also covers the subtler case of a company using it in its own internal tooling, because a company use is commercial use. The competition clause is narrower and it is explicit, which means the author has already thought about the case of someone presenting this at an event without permission.

The manifest does not set up any npm publication, and the README points readers to the built Windows executables instead of an install command, so there is no package to depend on programmatically.

The practical advice is narrow and concrete. Read the LICENSE file yourself, and if your use is anything other than personal, ask the author first. This review cannot tell you what a particular deployment counts as under PolyForm, and the licence is short enough that you can read it in the time it takes to build the app.

Smart recognition, not just decoding, is what the tool adds

A converter that only strips Base64 and wrapper characters would be a script. The interesting part of this project is what happens before and after the decoding.

The input handling is described as smart link recognition: the tool automatically detects all links in the input, identifies the protocol type, and auto-fixes common problems such as insufficient Base64 padding and a missing protocol prefix.

Each of those repairs corresponds to a real way these links break in practice. A Base64 payload that has lost its trailing padding will not decode with a standard decoder, and re-padding it is a one line fix. A link copied from a page or a chat client may arrive without its scheme, and the tool can restore it. Detecting multiple links in one paste means you can drop a whole list into the box rather than converting one at a time, which is what makes the batch save option worth having.

The output side is deliberately small and practical: the converted result is copied to the clipboard automatically, links can be opened directly in the browser to verify them, and results can be batch saved to a file. Opening the result in the browser is a genuine check rather than a convenience, because a decoded URL that resolves is the only proof that the decode was right.

The same principle applies to the eDonkey and magnet formats, which are not Base64 at all. Those are parsed as protocol fields and URI parameters respectively, so the decoder set in src/core/protocols is not five copies of the same function. It is five different parsers behind one interface, which is the part of this repository that would need the most care if the tool were extended to a format where the payload is not a URL at all.

A June release, then quiet

The release history is short and the most recent entry is recent enough to be worth reading closely.

The published tags are v2.0 from 2026-06-19, v1.6 from 2025-06-24, and v1.6_lite from 2025-06-23. The 2.0 release and the last push are the same day, 2026-06-19, which tells you that the current version was cut from a working tree rather than curated over a long period. The 1.6_lite tag alongside the full 1.6 tag, one day apart, suggests a stripped down variant was also produced.

The repository is not archived, and the last push was on 2026-06-19, which is about four months before the date of this writing. So the project is not dormant in the sense of being abandoned, but it is not on a visible release cadence either, and no release automation is described anywhere in the documentation.

What that means for a user is simple. The Windows installer and the portable archive are the delivery mechanism, and there is no package manager route, no source distribution for Linux or macOS and no documented build for them beyond the general Node and Electron toolchain. The build script has a Windows specific target, and the NSIS installer script is a Windows artefact.

For a contributor, the practical next steps are the ones in the documentation: install Node 18 or newer, clone the repository, run the install, and start the dev server. The README also points to the project structure and the core engine, so the first real task, adding a protocol, has an obvious home in src/core/protocols.

Editorial conclusion

Use Thunder-HTTPS if you keep downloads as encrypted links and want to turn them into something a browser or a download manager can open, and you are building for personal or non commercial use. Do not build it into a commercial product or bring it to a competition, because the PolyForm Noncommercial 1.0.0 licence requires written authorisation for that and the copyright notice says so explicitly. Before committing, read the LICENSE file yourself, run npm install and npm run dev on Node 18 or newer, and check the decoded output of each protocol against the link you started from, since a silently wrong URL is the failure mode that matters here.

Frequently asked questions

Official sources

1. helloworldpxy/thunder-https on GitHub
2. Issues
3. README
4. Releases