ULID generator

Both are 128 bits. A UUID v4 is pure randomness, so it carries no order; a ULID puts 48 bits of millisecond timestamp first and 80 bits of randomness after it. Sorted as strings, ULIDs are in creation order, which makes them good primary keys for databases that insert in time order.

Because Crockford Base32 spends 5 bits per character instead of 4, so 128 bits fit in 26 characters. The alphabet leaves out I, L, O and U so a value cannot be misread as a different one — the same reason VINs skip letters.

Not reliably. The specification has an optional monotonic mode that increments a counter inside the same millisecond, and this page does not implement it: the timestamp halves are identical and the randomness decides the order. If you need strict ordering inside one millisecond, keep a counter in your own database.

Yes — the first 48 bits are the creation time to the millisecond, readable by anyone holding the identifier. That is usually the point (sortable keys, log correlation), but it is a disclosure: an ID tells people when the row was created. A UUID v4 does not.

crypto.getRandomValues, the browser CSPRNG. Math.random is never used for an identifier here, and the page refuses to generate anything if that API is unavailable rather than falling back to something weaker.