Are these safe to put in a public tutorial or blog post?
The private ones are. A public-looking address such as 84.12.9.201 belongs to a real organisation, and publishing it in a code sample means readers may copy it into a script and send it real traffic. For documentation, use the RFC 5737 blocks that exist for exactly this purpose: 192.0.2.x, 198.51.100.x, and 203.0.113.x.
Can I generate addresses inside a specific subnet?
Not directly. There is no CIDR field. The private option gives you 10.x.x.x, 172.16-31.x.x, or 192.168.x.x picked at random, which covers most local-network test data, but if you need addresses inside, say, 10.42.7.0/24 you will need to build them yourself.
Why does the public option exclude 172 and 192 entirely?
Only part of each is reserved (172.16.0.0/12 and 192.168.0.0/16), but the generator excludes the whole first octet rather than doing range arithmetic. It errs toward never emitting a private or reserved address, at the cost of never emitting the public parts of 172.x and 192.x either.
Will the list contain duplicates?
It can. Each address is drawn independently and there is no deduplication pass. Across the full IPv4 space a duplicate in 5000 draws is very unlikely, but with the private 192.168 option, where only the last two octets vary, duplicates are common. Deduplicate downstream if uniqueness matters.
Are the addresses random enough for security work?
No. They come from Math.random, which is a fast pseudorandom generator, not the cryptographically secure crypto.getRandomValues. That is fine for mock data, sample logs, and load-test fixtures, and it is not fine for anything where an attacker predicting the next value would matter.