Password generators are often described as if they pour letters into a box. The interesting part is the construction. A useful generator states a length, states which character sets are in play, and then actually follows those rules. If you tick uppercase, lowercase, numbers, and symbols, and the result is sixteen lowercase letters, the page failed the request even if the string looks “random.”
The Password Generator on YallaSolve is built that way on purpose. Length is an integer from 8 to 128. The default is 16. You choose any combination of A–Z, a–z, 0–9, and a fixed symbol list: !@#$%^&*()-_=+[]{}:,.?. At least one set is required. If the length is smaller than the number of ticked sets, generation stops, because the page cannot place one character from each set. That is the whole first job: honor the form.
After the form is valid, the page takes one character from each selected set using crypto.getRandomValues. The remaining length is filled from the combined pool of those sets, with the same source. The array is then shuffled in place with cryptographic picks, so the required characters are not stuck at the front. Ticking symbols and still receiving a letters-only string is the usual silent failure. This construction refuses that failure.
The shuffle does not invent extra classes. If you untick numbers, digits are not in the pool. If you keep only lowercase, the result is lowercase of the requested length. That is honest. Filtering look-alike characters such as 0 and O would shrink the pool; the page does not do that.
Math.random is fine for a shuffle in a game. It is the wrong API for a secret. Password generators that use it are drawing from a generator that was never specified as a cryptographic source. YallaSolve’s password page calls crypto.getRandomValues. Integer picks use rejection sampling so a naive modulo does not bias the last characters of a set. If the browser cannot provide that API, generation stops. The page will not fall back to Math.random and pretend the result is the same kind of draw.
Cryptographic randomness is a statement about the draw, not a statement about the account you will paste into. A sixteen-character password with four classes is a reasonable default for a site that accepts those symbols. A bank that wants 24 characters is asking for more length, not a different brand of magic. The page will not score the result or call it unbreakable.
The value exists in the tab until you copy it or clear it. The password page does not write it to localStorage, sessionStorage, or cookies. It does not post it with fetch, XHR, or sendBeacon. Closing the tab discards the field. That is not a password manager. It will not remember the value for next week, and it will not hash the value for storage. A SHA-256 of a password is not a password-storage scheme; that job does not belong on a generator page.
Some sites reject a subset of the symbol list. If a form refuses one character, untick symbols or generate again. The page will not probe the remote site. It also will not claim the result survives reuse, phishing, or a breach of the service you paste it into. Length and variety help. They are not a guarantee.
The Random String Generator draws each character independently from one pool: letters, letters and numbers, hexadecimal, or URL-safe characters. There is no “at least one digit” rule. A short alphanumeric token can omit digits by chance. That is the correct behavior for a uniform token and the wrong behavior for a password policy that named classes.
Use the password page when the policy named classes. Use the random-string page when you need a hex nonce, a filename suffix, or a URL-safe token of a stated length. Do not treat either page as a UUID. A UUID has a fixed layout and version bits; that is a different generator.
How password generators create random passwords is a construction question. The useful answer names the length, the sets, the source of the draw, and the things the page will not promise. On YallaSolve the draw is Web Crypto, the sets are honored, and the value stays in the tab. Write the password into the account you are creating, then clear the field if other people can see the screen.
Yes on the Password Generator. Each ticked set contributes at least one character before the remaining length is filled from the combined pool.
No. The password page uses crypto.getRandomValues. If that API is missing, generation stops.
No. It is not written to local storage, session storage, or cookies, and it is not sent to a server by the tool.
No. The page will not say that. Length and character-set variety help. They are not a guarantee.