The difference is architectural, not incremental
TinyPNG works by receiving your file, compressing it with its own encoder, and sending back a smaller one. That design is why it can do what it does well, and it is also why the file has to exist, however briefly, on infrastructure that is not yours.
Softland reads the file with the canvas and image codecs already built into your browser. There is no upload step to wait through, no queue, and no copy anywhere except on your own disk. You can confirm this yourself: open the network tab, compress an image, and watch that no request carrying it is made.
When that actually matters
For a photograph of a landscape destined for a public blog post, it does not matter at all, and you should use whichever tool gives you the smaller file.
It matters for the other half of what people compress: a passport scan being shrunk to fit an upload limit, a signed contract, a medical letter, a screenshot with customer data in it, an unreleased product photograph, a design mock under embargo. Those are routinely put through whichever compressor came up first, and most people never consider that they have just posted the file to a third party.
On compression quality
A server-side encoder can afford to be slower and more thorough than one running in a browser tab, and on some PNGs TinyPNG will produce a smaller file than the browser will. That is a real advantage and it is worth being straightforward about.
In practice the gap is usually smaller than the gap you create yourself by resizing first. A 4000-pixel photograph displayed in a 600-pixel column is carrying more than ten times the data it needs, and no encoder on either side of the network recovers that for you. Resize to the display size, then compress, and the difference between encoders stops being the thing deciding your page weight.