Free Online Generators
Create QR codes, passwords and UUIDs that never leave your device.
Generators are the last category where uploading your input makes any sense — yet most free generators online still send your URL, password seed or UUID request to a server. SwiftTooly generates QR codes, passwords and UUIDs directly inside your browser using the Web Crypto API and well-known libraries. The output appears in the same tab that requested it, with no detour through anyone else's infrastructure.
3 Generators
Why use SwiftTooly's Generators
Cryptographic randomness
Passwords and UUIDs come from crypto.getRandomValues — true browser-grade entropy.
Never logged
Generated values are not stored, transmitted or replayed. Refresh and they're gone.
Customizable output
Choose QR size and color, password length and character set, UUID format and bulk count.
No watermarks
QR codes are clean PNGs — no branding pixel, no scan-tracking redirect.
Generators in your browser vs uploaded to a server
SwiftTooly (browser)
QR codes, passwords and UUIDs are generated by JavaScript inside the tab. Nothing about the value or how often you generate it leaves your device.
Typical upload-to-server tools
Server-side generators see every URL you encode and every password you produce, often log them, and sometimes route QR scans through their own tracker.
Why does the source of randomness matter?
Two of the three tools here depend on random numbers, and where that randomness comes from determines whether the output is trustworthy. JavaScript's Math.random() is a fast pseudo-random generator with no security guarantees — its output is predictable given enough observed samples, and it has caused real UUID collisions and weak passwords in production systems. The password and UUID generators here use crypto.getRandomValues(), part of the Web Crypto API, which draws from the operating system's cryptographically secure entropy pool — the same source that seeds TLS keys. That is what makes a generated password genuinely unguessable and a version 4 UUID genuinely unlikely to collide. It is also why generation has to happen somewhere with access to that entropy pool, which your browser has and a naive server-side generator may not use correctly.
Why generating locally is the right architecture
A password generated on someone else's server has existed on infrastructure you do not control. It crossed a network, sat in that machine's memory, and may have been written to a log, a crash dump or a cache without anyone intending it. Even a completely honest operator cannot remove that attack surface — it is inherent to the architecture. Generating in the browser eliminates it. The value is produced by your own device, exists only in the tab's memory, and is gone when you close the page. You can verify this rather than trusting it: open your browser's developer tools, watch the Network tab while generating, and observe that no request is made. Disconnecting from the internet and generating anyway is an even simpler test. The same reasoning applies to QR codes, where the encoded payload may be a WiFi password or personal contact details — encoding locally means those never leave the device either.
Static QR codes and what you give up
The QR generator produces static codes, which is a deliberate choice with a real trade-off. A static code encodes your content directly into the module pattern, so scanning reads it with nothing in between. It never expires, requires no account, and nobody logs who scanned it or when. What you give up is editability and analytics. A dynamic QR — the kind most commercial generators sell — encodes a short URL owned by the provider, which redirects to your destination. That lets you change the target after printing and count scans, at the cost of depending on that company continuing to exist and route your traffic. When such a service shuts down or a subscription lapses, every printed code becomes dead, and physical material already distributed cannot be fixed. If you want both properties, the answer is to encode a URL on a domain you control and put the redirect there. You keep the ability to change the destination and to measure scans, without handing either to a third party. The same reasoning explains why there is no account system here. An account would mean storing something, and everything these generators produce is meant to be ephemeral — a password you paste into a manager, a UUID you paste into a config, a QR you download and print. Nothing needs to persist on our side, so nothing does.
Related collections
Frequently asked questions
Can someone else see the password I generate?
- No. The Password Generator uses the browser's Web Crypto API. The value only exists in your tab's memory until you copy it somewhere safe.
Are the QR codes I generate trackable?
- No. SwiftTooly's QR codes encode your raw URL directly. There's no redirect through our domain and no scan analytics — anyone who scans goes straight to the destination.
Which UUID versions are supported?
- RFC-4122 version 4 (random) by default, with the option to generate version 7 (time-ordered) for database-friendly inserts.
Do the generated values expire?
- No. Static QR codes, passwords and UUIDs never expire — they last as long as you need them.