Cyberchef!

I mean… It’s decoding into garbage because you’re feeding it more than just the base64 section. I suppose if you’re already running nginx or something you could easily make a page that uses javascript to break the link down (possibly using /, ?, = as separators) and decode sections that look like base64. If you make it javascript and client side there’s not really any privacy concerns.

EDIT: Oops. My Lemmy client didn’t load the other replies at first, I didn’t realize you already had plenty of other options.

It’s 3 lines of code in basically every programming language, no need for selfhosting, just open the terminal?

I have nothing to add except the appreciation for everyone who helped and amazement at the vastly differing ways people produced working results.

I’ve been working on a URL cleaning tool for almost 2 years now and just committed support for that type of URL. I’ll release it to crates.io shortly after Rust 1.90 on the 18th.

https://github.com/Scripter17/url-cleaner

It has 3 frontends right now: a CLI, an HTTP server and userscript to clean every URL on every webpage you visit, and a discord bot. If you want any other integration let me know and I’ll see what I can do.

Also, amusingly, you decoded the base64 wrong. You forgot to change the _ to / and thus missed the /burger-dog-mold and tracking parameter garbage at the end. I made sure to remove the tracking parameters.

Edit: Published on crates.io and github under AGPL. Sadly the discord frontend couldn’t be published to crates.io because to work around something (I forget exactly what) I changed a dependency from the one on crates.io to a more up-to-date version of it on github. Crates.io correctly rejects that kind of stuff. If you want to use the discord frontend, git clone the repository then run cargo build -r -p url-cleaner-discord-app.

The offer to write extra frontends stands, btw. If you want a slack bot I’ll make one.

CorentinTh/it-tools does that and a lot more

The encoding format of URLs is URL encoding, also known as percent-encoding. Content in the URL may be first encoding in some other format, like JSON or base64, and then encoded additionally using percent-encoding.

While there is a standard way to decode percent-encoding, websites are free to use base64 or JSON in URLs however they wish, so there’s not a one-size-fits-all way to decode them all. For example, the “/” character is valid in both percent-encoding and base64-encoding, so to know if it’s part of a base64-encoded blob or not, you might end up trying decoding several parts of the URL as base64 and checking if the result looks like URL-- essentially brute force.

A smarter way to do this might be to maintain a mapping between your favorite sites that you want to decode and what methods they use to encode links. Then a tool could efficiently directly decode the URLs embedded in these click trackers.

Not that you should vibe code, but you could vibe code this so easily. Have it output a static website. Give the source code a scan if you’re paranoid. Check the network tab if you’re really really paranoid. But literally you could have it output this as a static index.html file that you drop into your browser of choice.

This is the only type of coding LLMs should ever be used for imo. A small, very clearly defined task that is very easy to verify if it works. And code that won’t infect a larger project.

Edit: as others pointed out, that url isn’t base64 encoded. You would have to clearly define what you are trying to do if you want this to work. For example, do all urls follow the same format as the above?