shred of a single file only has any hopes of being secure as long as you can guarantee no other copies of that file have ever been made. This might work well for really big files (movies) — assuming you don't re-encode those, and not well at all for small files, documents and everything you actually work with.
Every time you click 'Save', bam you have another copy. Because saving truncates the file to 0 bytes and writes a new file — usually at a physically different location. Even the filesystem no longer knows where the old copy was located, so no way to delete that with shred or any other utility.
And so you end up overwriting all free space instead. This is a lot better than shredding single files, but comes with its own pitfalls... you need to be root to also overwrite the root reserve, and filesystems don't like being full at all — any other writes going on at the same time will fail, thus you end up with actual data loss in the process.
So like this method:
truncate -s 1E sparsefile
shred -v -n 1 sparsefile
sync # other programs will lose data at this point
rm sparsefile
With SSD you get the zerofree as a built-in feature, fstrim/discard does exactly that, gets rid of free space quickly and easily. Basically with SSD you won't be able to recover any deleted files after trim has occured.
Is it safe? That depends on the filesystem, and the size of the file you wanted to get rid of. Some filesystems have nooks and crannies, like multiple small files sharing a single block, and that space won't be overwritten when creating one whopping big file full of random data. Also there might still be other traces, such as a leftover filename in a directory entry...
You can't beat overwriting the entire device once.
# backup everything
blkdiscard /dev/sda # SSD
shred -v -n 1 /dev/sda # HDD
# create partitions, filesystems, restore backup