Assemblies in Encoding Tools

Back in June, I posted about a project called Encoding Tools, which is an open source, browser-based utility for transforming text and binary strings. The purpose of this project is partially to scratch an itch, but also to have some fun building a project that I can market publicly. This post is an update on the project.


When I first started working on Encoding Tools, I was motivated by my frustration with existing tools—and I thought I knew about all of the existing tools. After posting, somebody contacted me on Twitter to tell me about CyberChef, which is a tool created by GCHQ—the UK’s secret squirrel spy agency! I have to kick myself twice for not looking at CyberChef in my first post: once because I should have found it in my “market research”, and a second time because I realized I had seen it a few years ago and then forgotten about it! Here’s a quick example of CyberChef doing a hex decode followed by base64 encode:

CyberChef example

And here’s the same operation in Encoding Tools:

Encoding Tools example

I won’t do a full rundown of CyberChef features, but it is a very comprehensive tool that offers a bunch of functionality. There are things I like and dislike about CyberChef, but it’s fundamentally a very different take on the UX. CyberChef treats the sequence of operations as a “recipe” and displays only the input to the first operation and the output of the last operation. This decision allows for maximal space devoted to viewing inputs and outputs, but also hides interim values. Encoding Tools shows you each interim value in real-time.

CyberChef also has some really complex features like flow control and loops. I would guess that CyberChef is probably a Turing-complete programming language! This is another differentiator that distinguishes CyberChef from Encoding Tools: I wanted to create a tool that is not overly complicated. If I really wanted a Turing-complete programming language to compute hashes and encodings, I would just open up the Python REPL.

Overall, I believe that there’s room for both types of tools in the “market”. (I keep putting these business-y words in quotes, because both CyberChef and Encoding Tools are open source and free to use! I’ll omit the quotes from here on out.) So I am pushing forward on this project, because I’m still having fun and learning from it.


I released Encoding Tools back on June 27th. I posted it to my meagre Twitter following, e-mailed a few people I thought might care, and most helpfully got my buddy Alex to amplify to his large Twitter audience. I sat back and waited for the traffic surge! Drum roll…

Encoding Tools 5 months traffic: 12, 5, 19, 36, 7.

Yikes. I switched my tracker from Google Analytics to Matomo in early July, so my June traffic doesn’t appear in this graph. (It wasn’t much better than July.)

Although the traffic numbers are disappointing, they do validate one of the concerns made in my first post: before I write a bunch of code and polish and refactor a dozen features, I need to gauge market interest in my project. The low traffic numbers tell me that investing a lot more time in June would have probably been a bad idea. Instead, I launched and started to get feedback, both qualitative and quantitative.

Alberto Savoia, Pretotype Labs LLC
Before you build it right, build the right it.

So instead of seeing low traffic as a major setback, I see it as a motivation to revisit my assumptions and focus my energy where it’s most needed.


Without a doubt, the next goal in this pet project needs to be growing the audience. I suspect that the project lacks mindshare, i.e. many potential users have either never heard of it, or they heard about it and then forgot.

A quick anecdote drives this point home: one day I was screen sharing with my pal Alex (keep in mind, this is the same guy who tweeted about my project), and we were pair programming on a memory corruption exploit. At one point, Alex switched to a browser tab opened to The conversation that ensued was something like this:

Mark: “Dude, come on, you gotta use my Encoding Tools!!”

Alex: “Ohhhh yeah… I remember that. What’s the URL again?”

Mark: (Furrows brow) “It’s encoding… dot… tools…”

I know that Alex searched for “base64 decoder” and randomly clicked one of the top 10 results. I know this because it’s exactly what I used to do before I created Encoding Tools. Side note: CyberChef doesn’t crack the top 10 results, either!

Getting to the top of these results organically will be quite a challenge, especially for all of the different keywords like hex, MD5, etc. I think it will be far cheaper (when pricing my own time) to simply buy my way to the top. The fun think about competing with a bunch of free tools is that the ads are super cheap. For a few bucks a month, I can get hundreds of clicks for keywords like “base64 decode”.

The only catch? If somebody clicks on a base64 decoder ad, then they expect to see a base64 decoder tool, but Encoding Tools is DIY: you have to assemble the gadgets yourself. Advertising will be fruitless if users land on the site and don’t know what to do next.


One of my coworkers, Luke, has a background in digital marketing and SEO. He gave me a brilliant idea, one of those sounds-obvious-after-you-hear-it ideas: special URLs should load pre-configured gadgets. For example, the URL hash #base64-decoder can load up Encoding Tools with an input gadget that is piped to a base64 decoder gadget.

So today I wrote code to support this feature! I call these pre-built things assemblies, and there are a handful of “static assemblies” that are hard-coded and loaded automatically based on the URL hash. Today’s code also lays the foundation for saving, loading, and sharing assemblies in the future.

Here is an example of the new assembly feature. The URL hash is #url-decoder, so Encoding Tools creates the corresponding gadgets and pipes automatically. It also updates the title in the tab and the nav bar so that browser history (and hopefully search engine results) will show appropriate titles.

Loading assembly from URL hash.
Loading assembly from URL hash.

For users who are not arriving from search engine results, I also put a list of assemblies in the toolbox. (Oh by the way, the “drawer” was renamed to “toolbox”, a change so blindingly obvious I can’t believe I called it “drawer” in the first place.)

Loading assembly from toolbox.
Loading assembly from toolbox.

Notice how the SHA-1 assembly contain two pipelines: one for hashing plaintext and another for hashing binary data. As with the previous work on this project, I resisted the urge to go crazy polishing this new feature. The UI isn’t totally beautiful, but it’s minimal and viable and will help me validate the assumption underlying today’s work: users would use this tool more if it was easier to find in search engines.

With this new feature in place, I can now place ads on the keywords I mentioned above. I created Bing and Google campaigns for this and other keywords like “hex encoder” and “url decoder” with 1¢ bids. I’m going to run these campaigns for a few months, and hopefully the next blog post in this series will be an update on traffic growth!

As part of series of posts, I’m tracking the project’s costs. Today’s effort was 7 hours of labor and $0 dollars cash, bringing the project total to 55 hours and $29! Follow me on Twitter or subscribe to this site via RSS for project updates. If you have feature requests or bug reports, please create an issue on GitHub.