Current list of tools: html, css, js compressor, image to base64, json to csv, csv to json, OCR Reader, unzipper (browser only).
Built with react.js (next.js framework) and node.js. Uses some open source packages.
This list may not be representative of “all free online tools” but is sufficient for the context. Perhaps the common thread amongst all of them is that they are served over the interweb. And I wonder what’s the use case?
The use case of OCR is you know, but for compressor like html, css and js is not much due to build tools like webpack or gulp, but it can have. Whenever I want to build a static website quickly or building theme for ghost blogging platform, I search for compressor on the web for quickly testing the compressed output.
Another thing is when I started building this website for my web dev practice, I want to present the simplest tools that can be build quickly. Some of them is the result of that.
I'll put a privacy policy page soon. It's just start. Most of the tools I'll put on the website is either browser based or don't rely on any storage. Currently no database system is used on website, so you're safe. Things like compressor (html, css, js) is done directly on memory.
In my bookmarks I have HTML encode/decode and URL encode/decode. Have you considered creating a single input and single output field with different buttons around?
I'm curious, who here has a development workflow such that compressing/minifying code via an ad-hoc web tool makes sense? I've always just included it as part of a build process, or at the very least would pipe it into uglifyjs command line. I'm sure everyone's got their own needs but I just don't understand how that would be useful.
You're touching up an old website for your old client and have just a few minutes to...ah, I wonder if there's a quick minimizer out there somewhere? That might be fun to try, and we did just add a bit more overhead to the site.
I haven't done this exact thing, but I've done similar things many times. Not every project has or should have a build process. And unfortunately not all of them even have a command line...
If you don't have an established build process, I would consider a one-time minification of an established codebase to be a pretty poor decision.
Either setup a trivial build script, or don't do it at all.
EDIT: Clearly HN disagrees with me. Tell me, what does being a cowboy get you here?
If it's a measurable performance boost, then as soon as you patch it again your site will seem slower. Unless you then manually minifiy again. And again. Until you setup a build script.
If it's not a measurable performance boost, (And I doubt that you know either way because if you're not setting up a trivial build script then I highly doubt you're putting in the time to profile) then what do you get? The next person to come along gets to have a harder time debugging because you don't have source maps?
I agree. Minify once it's released and you can test it quickly once to make sure there's no reference screw-ups, but as part of your development process - don't touch that file. I'd say most web developers follow this process though, I'd be interested to see statistics on minified sources. I'd say at least half of the websites I right-click view-source don't minify.
and stats on how many times these minify and unminify sites have been used would be interesting.
I've used them more than a dozen times. Some sites get the minification just to ramp up a google pagespeed number - not really for the end users - so why bother with a build process?
Write some html, ftp. Then pagespeed numbers matter to some people and in some competitive industries - view source, web minify, ftp. done.
Looks neat! My one critique is the Contact Us link. I find unexpected mailto: links annoying because they cause my desktop mail client (which I don't use) to open unexpectedly when I'm expecting to be taken to a page, in this case a Contact Us page.
Perfectly reasonable. I would then suggest changing it from "Contact Us" to "hello@hreftools.com" to prevent any confusion (Principle of Least Astonishment) :)
What is the HTML compressor using? It’s missing quite a few opportunities.
Take this input HTML:
<!doctype html>
<html lang="en-au">
<head>
<meta charset="utf-8">
<title>This is a title</title>
</head>
<body class="foo">
<h1>Well.</h1>
<p>I wonder…</p>
</body>
</html>
It produces this output:
<!DOCTYPE html><html lang="en-au"><head><meta charset="utf-8"><title>This is a title</title></head><body class="foo"><h1>Well.</h1><p>I wonder…</p></body></html>
It converted “doctype” to uppercase (equivalent, but bad for compression). It didn’t strip <head> and </head> as superfluous. It didn’t remove unnecessary quotes around attribute values. It didn’t remove the unnecessary </p></body></html> closing tags.
Here’s what I say it should have emitted:
<!doctype html><html lang=en-au><meta charset=utf-8><title>This is a title</title><body class=foo><h1>Well.</h1><p>I wonder…
30 characters shorter, and structurally equivalent.
The point is that this is legal HTML. The HTML spec does define all kinds of things as illegal (though it defines how the parser should handle them, for reasons of security and consistency), but these things are all legal. All have had the same behaviour forever, though omitting <html>, <head> and <body> tags being legal is, I believe, new to HTML 5. But the rest (e.g. not closing a paragraph tag and not using quotes on simple attribute values) have been legal from the very start, and even popular, though they have fallen out of favour for authoring in recent years.
This is absolutely nothing to do with Postel’s law. I believe that Postel’s law is a terrible idea in most places—it leads to a lack of robustness in practice, and all kinds of security problems, because most programmers are frankly not good at their trade. Rather, the HTML spec defines all behaviour—so there is no liberality about it; you’re simply following the spec with no interpretation—which is the only way to write robust protocols and their implementations.
If it complies to the spec, it's by definition valid syntax and suitable for production. Now whether or not you want that in your source code is totally up to you.
Just because you can write your whole app in one line of JavaScript doesn't mean you should maintain that as source code. You sure want that as your production bundle though.
maybe it's just me but i feel like using of any of these "tools" would slow me down when compared to using the equivalent shell-foo or a language built-in/library.
also seems like a terribly brittle externality to add to my life
36 comments
[ 219 ms ] story [ 1257 ms ] threadThis list may not be representative of “all free online tools” but is sufficient for the context. Perhaps the common thread amongst all of them is that they are served over the interweb. And I wonder what’s the use case?
Edit: typo
[1] https://gchq.github.io/CyberChef/
It's my go-to Numberwang encoder!
Check out https://jsonchecker.com/
It validates and formats JSON.
Let me know if you have any feedback!
I haven't done this exact thing, but I've done similar things many times. Not every project has or should have a build process. And unfortunately not all of them even have a command line...
Either setup a trivial build script, or don't do it at all.
EDIT: Clearly HN disagrees with me. Tell me, what does being a cowboy get you here?
If it's a measurable performance boost, then as soon as you patch it again your site will seem slower. Unless you then manually minifiy again. And again. Until you setup a build script.
If it's not a measurable performance boost, (And I doubt that you know either way because if you're not setting up a trivial build script then I highly doubt you're putting in the time to profile) then what do you get? The next person to come along gets to have a harder time debugging because you don't have source maps?
I've used them more than a dozen times. Some sites get the minification just to ramp up a google pagespeed number - not really for the end users - so why bother with a build process? Write some html, ftp. Then pagespeed numbers matter to some people and in some competitive industries - view source, web minify, ftp. done.
If it's critical to the business needs, script it. If you need to do it every time you fix a bug, make it automatic.
Take this input HTML:
It produces this output: It converted “doctype” to uppercase (equivalent, but bad for compression). It didn’t strip <head> and </head> as superfluous. It didn’t remove unnecessary quotes around attribute values. It didn’t remove the unnecessary </p></body></html> closing tags.Here’s what I say it should have emitted:
30 characters shorter, and structurally equivalent.This is absolutely nothing to do with Postel’s law. I believe that Postel’s law is a terrible idea in most places—it leads to a lack of robustness in practice, and all kinds of security problems, because most programmers are frankly not good at their trade. Rather, the HTML spec defines all behaviour—so there is no liberality about it; you’re simply following the spec with no interpretation—which is the only way to write robust protocols and their implementations.
Just because you can write your whole app in one line of JavaScript doesn't mean you should maintain that as source code. You sure want that as your production bundle though.
also seems like a terribly brittle externality to add to my life