UUID生成ツール

ランダムなUUID v4や時刻順のUUID v7をすぐに生成でき、最大10,000個まで一括で作成できます。GUIDも同じ種類の128ビットの値なので、オンラインのGUID生成ツールとしても使えます。UUIDを貼り付けると、バージョン、作成時刻、すべてのフィールドをデコードします。

RFC 9562 · crypto.getRandomValues · ブラウザー内で作成・解析し、何も送信しません

色付きの数字がバージョンです。どのUUIDでも、3番目のグループの最初の桁にあたります。

v4 · ランダム36文字 · ランダム122ビット
xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx
構造 · RFC 9562 §5.4128ビット · 16進数32桁 · 36文字
フィールドにカーソルを合わせるかタップすると、説明が表示されます

crypto.getRandomValuesを使い、ブラウザー内で作成・解析します。何も送信されません。

形式

UUIDとは?UUIDは何の略か

UUIDはUniversally Unique Identifier(汎用一意識別子)の略です。どのコンピューターでも単独で作成でき、それでも他のコンピューターと同じ値にはならないと見なせる128ビットのラベルです。919108f7-52d1-4320-9bac-f847db4148a8 のように、16進数32桁を5つのグループに分けて書きます。

形式はRFC 9562(2024年5月)で定められています。RFC 4122に代わる規格で、バージョン6、7、8が追加されました。UUIDを発行する中央の登録機関はなく、一意性はバージョンに応じて、乱数、タイムスタンプ、名前のハッシュのいずれかから生まれます。

データベースでは主キーとして、APIではリクエストやオブジェクトのIDとして、OSではディスク、パーティション、ソフトウェアコンポーネントの識別に使われます。GUID(Globally Unique Identifier)は、同じものに対するMicrosoftの呼び名です。

1つの値を4通りで数えるRFC 9562 §4

UniversallyUniqueIDentifier

  1. 128 ビット
  2. 16 バイト
  3. 32 桁の16進数
  4. 36 文字(ハイフン込み)919108f7-52d1-4320-9bac-f847db4148a8

GUID同じ値に対するMicrosoftの呼び名

RFC 9562のバージョン4の例を4通りで数えたものです。テキスト形式では16進数32桁にハイフン4つが加わり、36文字になります。
UUID生成ツールの画面:タイムスタンプ、バージョン、ランダムビットをフィールドごとに色分けしたUUID v7と、一括生成したv7 UUIDのリストUUID生成ツールの画面:タイムスタンプ、バージョン、ランダムビットをフィールドごとに色分けしたUUID v7と、一括生成したv7 UUIDのリストバージョンを選ぶランダムなv4、時刻順のv7、名前ベースのv5などを、それぞれの色で表示します。ワンクリックコピーも再生成もすぐにできます。最大10,000個の一括生成は、テキスト、CSV、JSON、SQLで出力できます。すべてのフィールドこのバージョンについてRFC 9562が定義するビットを示し、v7に含まれる時刻も読み取ります。どの形式でも波かっこ、ハイフンなし、大文字、Base64url、整数、.NETのバイト順で表示できます。
UUID v7を分解したところです:48ビットのタイムスタンプ、バージョンの数字、バリアントのビット、ランダムな部分。番号を選ぶと、各部分に何が表示されているかを確認できます。

UUIDの形式と長さ:36文字

UUIDは128ビットで、16進数32桁とハイフン4つを8、4、4、4、12桁のグループに分けて書くため、36文字になります。3番目のグループの最初の桁がバージョンを、4番目のグループの最初の桁がバリアントを示し、RFC 9562のUUIDでは後者が8、9、a、bのいずれかになります。

つまり 017f22e2-79b0-7cc3-98c4-dc0c0c07398f はバージョン7で、RFCのバリアントです。大文字、小文字、混在のいずれも有効で、多くのツールは小文字で出力しますが、macOSの uuidgen は大文字です。ハイフンなしでは32文字、波かっこ付き(.NETの B 形式)では38文字、urn:uuid: 付きでは45文字、Base64urlでは22文字になります。

RFCの形式をチェックする正規表現は、^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ に大文字・小文字を区別しないフラグを付けたものです。有効ながら特別な値であるNil UUIDとMax UUIDははじかれますが、上のデコーダーはそれらも判別します。

テキスト形式RFC 9562 §4
017f22e28-79b04-7cc34-98c44-dc0c0c07398f12

16進数32桁 + ハイフン4つ = 36文字

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxM バージョン:1〜8N バリアント:8、9、a、b
正規表現 · 大文字・小文字を区別しない^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$
同じ128ビットの別の書き方
  • 標準017f22e2-79b0-7cc3-98c4-dc0c0c07398f36
  • ハイフンなし017f22e279b07cc398c4dc0c0c07398f32
  • 波かっこ {…}{017f22e2-79b0-7cc3-98c4-dc0c0c07398f}38
  • urn:uuid:urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f45
  • Base64urlAX8i4nmwfMOYxNwMDAc5jw22
  • Base64AX8i4nmwfMOYxNwMDAc5jw==24
  • Base58BihbxwwQ4NZZpKRH9JDCz21
  • Base3201FWHE4YDGFK1SHH6W1G60EECF26
  • 整数1989357241971137676463954034883508623最大39
  • バイナリ01 7f 22 e2 79 b0 7c c3 98 c4 dc 0c 0c 07 39 8f16バイト
RFC 9562自身のv7の例を各形式で書いたものです。正規表現がNil UUIDとMax UUIDをはじくのは意図的です。これらにはバージョンがないためです。

UUIDのバージョンを解説:v1からv8まで

バージョンはUUIDの作り方を示します。v4は乱数から、v7は時刻と乱数から、v1とv6はタイムスタンプとノードIDから、v3とv5は名前のハッシュから作られ、v8は作成側独自のレイアウトです。

バージョン2と0は、ここでは生成しません。v2(DCEセキュリティ)は予約されているものの、RFC 9562ではレイアウトが定義されておらず、0はバージョンではありません。2つの特別な値にはバージョンがなく、Nil UUIDはすべてのビットが0、Max UUIDはすべてのビットが1です(ffffffff-ffff-ffff-ffff-ffffffffffff、RFC 9562で新設)。

新しいシステムには、RFC 9562はv1やv6よりv7を、v3よりv5を推奨しています。値から作成時刻を一切読み取れないようにしたい場合は、v4が素直な選択肢です。

バージョン128ビットの内訳作成方法時刻順ソート
v1時刻 + ノード · §5.1時刻(100ナノ秒)+ クロックシーケンス + ノード不可
v2DCEセキュリティ:予約済みで、RFC 9562にレイアウトの定義なし生成しない:レイアウトの定義なし–
v3名前 · MD5 · §5.3名前空間 + 名前のMD5不可
v4ランダム · §5.4ランダムビット不可
v5名前 · SHA-1 · §5.5名前空間 + 名前のSHA-1不可
v6ソート可能なv1 · §5.6v1のフィールド、時刻の上位ビットが先頭可
v7時刻順 · §5.7Unix時間(ミリ秒)+ ランダムビット可
v8カスタム · §5.8作成側独自のレイアウト不可
Nil§5.9すべて0:「値なし」–
Max§5.10すべて1:番兵値–
  • 時刻
  • ランダム
  • ハッシュ
  • クロックシーケンス
  • ノード
  • バージョン
  • バリアント
各バーは、RFC 9562のテストベクターをもとに、各バージョンの128ビットをRFCのレイアウトどおりに示したものです。時刻を先頭に置くのはv6とv7だけなので、テキストのまま時刻順にソートできるのもこの2つだけです。

UUID v4とv7の違い:どちらを使うべき?

データベースのキーや、ソートやインデックスの対象にはv7を使います。先頭が作成時刻なので、新しい行はインデックスの末尾に追加されます。IDから作成時刻を知られたくない場合はv4を使います。UUIDv4とは、自由に使える122ビットがすべてランダムなUUIDです。

ランダムなv4のキーは、挿入のたびにB-treeインデックスのあちこちに散らばるため、ページ分割が起き、インデックスのより多くの部分をメモリーに載せておく必要が生じます。v7のキーは自動採番の数値のように順番に届きますが、どのサーバーでもデータベースに問い合わせずに作成できます。v7は1ミリ秒ごとに74ビットの乱数を持つため、2台のサーバーが同じ瞬間に作成しても衝突しません。

トレードオフとして、v7を見た人は誰でも、それが作成されたミリ秒を読み取れます(上のデコーダーに貼り付けてみてください)。それが問題になる場合は、v4を使うか、v7は内部だけで使い、外部には別のIDを公開してください。

B-treeインデックスへの12回の挿入リーフページ8つ · 各16キー
v4のキーはどこにでも入る8ページ中7ページに挿入 · ページ分割3回
先頭バイト別のページ
00–1f分割
20–3f
40–5f
60–7f
80–9f
a0–bf
c0–df分割
e0–ff分割
c100eb4b-4f3f-4b29-ad77-da7cd9d1eda592c97333-2db8-4fc2-b5b6-cedd8c7abede
v7のキーは末尾に入る8ページ中1ページに挿入 · ページ分割0回
キーが作成された日別のページ
10月17日
10月18日
10月19日
10月20日
10月21日
10月22日
10月23日
10月24日
01a16d3e-e1c0-70f6-99ec-6d454991b2fa01a16d3e-e1c0-70f6-99ec-6d45c2f6b35b
  • インデックスにある既存のキー
  • 空き
  • 新しいv4
  • 新しいv7
  • ページ分割:キーの半分が新しいページへ移動
ベンチマークではなくモデルで、リーフページは16キーずつです。ランダムなキーはほぼ満杯の古いページに入って分割を起こします。v7は先頭バイトが時刻なので、12個すべてがまだ空きのある最新のページに入ります。

GUIDとUUIDの違いは?

GUIDとUUIDは、同じテキスト形式で表される同じ128ビットの値で、GUIDはMicrosoftでの呼び名です。.NETの Guid.NewGuid() はランダムなバージョン4のUUIDを、.NET 9の Guid.CreateVersion7() はバージョン7のUUIDを作成します。

違いはメモリー上の表現にあります。MicrosoftのGUID構造体は最初の3つのグループをリトルエンディアンの整数として格納するため、.NETの ToByteArray() では、先頭8バイトがRFC 9562のネットワークバイト順とは異なる順序になります。919108f7-52d1-… は、バイト列 f7 08 91 91 d1 52 … になります。テキストは同じでも、システム間でやり取りする生のバイト列は変換が必要です。デコーダーは両方の順序を表示します。

さらにSQL Serverの uniqueidentifier は最後の6バイトを優先して並べるため、v7の値もそこでは時刻順を保てません。NEWSEQUENTIALID() は時刻順を保つ値を作りますが、再起動後に小さい値から始まり直すことがあり、推測も容易です。古いCOMのGUIDは、RFC 9562のものではなくMicrosoft独自のバリアントビットを持つことがあり、デコーダーはそのバリアント名を表示します。

1つのGUID、3つのバイト順16バイト
919108f7-52d1-4320-9bac-f847db4148a8
RFC 9562 ネットワークバイト順
.NET Guid.ToByteArray()
SQL Server uniqueidentifierの順序最後の6バイトで順序が決まる
  • Data1 · 4バイト、逆順
  • Data2 · 逆順
  • Data3 · 逆順
  • Data4 · そのまま
同じテキストのメモリー上の表現です。.NETは最初の3つのグループをリトルエンディアンで格納し、SQL Serverは最後の6バイトを優先して並べるため、時刻順のv7のキーもそこでは順序を保てません。

コードでUUIDを生成する方法

ほとんどの言語ではv4のUUIDを1行で作成でき、v7に対応する言語も増えています。Python 3.14の uuid.uuid7()、.NET 9の Guid.CreateVersion7()、Java 26の UUID.ofEpochMillis()、Go 1.27の uuid.NewV7()、Node.js 26.1の crypto.randomUUIDv7()、PostgreSQL 18の uuidv7() です。ブラウザーには今も、v4を作る crypto.randomUUID() しかありません。

言語を選ぶと、1行のコードが表示されます。同じミリ秒内に作られたUUIDの順序を、どのv7も保つわけではありません。PythonとGoは保ちますが、.NETとNode.jsは保証していません。また、MySQLの UUID() はバージョン1のUUIDを返し、LinuxとWindowsではサーバーの実際のMACアドレスを含みます。

言語ごとの組み込みUUID関数

Python
import uuid

uuid.uuid4()   # v4
uuid.uuid7()   # v7, Python 3.14+
uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.com")  # v5

uuid7()は42ビットのカウンターを持つため、同じミリ秒のUUIDも順序が保たれます。

各言語の公式ドキュメントに記載されたバージョンです。マークは各プロジェクトのロゴです。

2つのUUIDが同じになることはある?

理論上はありえますが、実際にはありません。v4のUUIDはランダムな122ビットを持ち、値は約5.3 × 10³⁶通りあります。いずれか2つが一致する確率が10億分の1になるには約103兆個、五分五分になるには約271京個を作る必要があります。

これは誕生日問題による上限(バースデーバウンド)です。N通りの中からn個のランダムな値を選ぶと、重複が起きる確率は約1 − e^(−n(n−1)/2N)です。1秒に10億個のUUIDを作っても、確率が50%になるまでには約86年かかります。実際の重複は、壊れたジェネレーターから生じます。ランダムでないシード、乱数の状態ごと複製された仮想マシン、手作業でコピーされたIDなどです。

v7で一致する可能性があるのは、同じミリ秒に作られたUUID同士だけで、それらを区別するのは74ビットの乱数です。このページのジェネレーターは、1ミリ秒内でも一括生成の順序を保つため(RFC 9562 §6.2)、10,000個を一度に作っても重複がなく、ソートされた状態になります。

誕生日問題による確率当サイトの計算
いずれか2つが一致する確率1.1 × 1019分の1p ≈ 9.4 × 10−20

1秒に10億個のペースでも、その数を作るには1 秒かかります。

p ≈ 1 − e^(−n(n−1)/2N)。Nはv4では2¹²²、v7では1ミリ秒あたり2⁷⁴です。RFC 9562は衝突の確率を示していないため、これはページと同じ関数を使った当サイトの計算です。

UUIDデコーダー:UUIDからタイムスタンプを読み取る方法

上のUUIDデコーダー兼バリデーターである「デコードと検証」にUUIDを貼り付けてください。決まった2か所からバージョンとバリアントを読み取り、続いてそのバージョンが定義するフィールドを読み取ります。v7からは作成されたミリ秒が、v1やv6からは100ナノ秒単位の時刻とクロックシーケンス、ノードIDが分かります。

v1やv6のノードでマルチキャストビットが立っていない場合は、ネットワークカードの実際のMACアドレスかもしれません。MACアドレス検索でメーカーを調べられます。プライバシーに配慮したジェネレーターはこのビットを立ててランダムなノードを使い、このツールもそうしています。

時刻はジェネレーターが書き込んだものであり、UUIDが作成された時刻の証明ではありません。v4には時刻がなくランダムビットだけ、v3、v5、v8にはハッシュが入っているため読み取れるものはなく、ハッシュから名前を復元することもできません。リストを貼り付けると最大1,000個をまとめてチェックでき、無効な行、重複、時刻ベースのUUIDが順番どおりかが分かります。

同じ瞬間の2通りの書き方RFC 9562 · Appendix A
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
  1. unix_ts_ms0x017f22e279b0
  2. 1970年からのミリ秒1 645 557 742 000
  3. UTC2022-02-22T19:22:22.000Z
c232ab00-9414-11ec-b3c8-9f6bdeced846
  1. time_high · time_mid · time_low1ec 9414 c232ab00
  2. 1582-10-15からの100ナノ秒刻み138 648 505 420 000 000
  3. UTC2022-02-22T19:22:22.0000000Z

同じ瞬間です。RFC 9562の例は同時に作られました。

v7は1970年からのミリ秒で始まります。v1は時刻の下位部分を先に格納するため、デコーダーは3つの部分を正しい順に並べ直してから、1582年10月15日を起点に数えます。

名前ベースのUUID:v5とv3

v5のUUIDは、名前空間UUIDと名前を合わせたもののSHA-1ハッシュを128ビットに切り詰め、バージョンとバリアントを設定したものです。v3は同じことをMD5で行います。名前空間と名前が同じなら、どのコンピューターでも必ず同じUUIDになります。上でv5を選ぶと、このページをUUID v5生成ツールとして使えます。

RFC 9562は4つの名前空間を定義しています:ドメイン名用のDNS、URL、OID、X.500です。たとえばDNS名前空間の www.example.com は、v5では常に 2ed6657d-e927-568b-95e1-2665a8aea6a2 になります。名前ベースのUUIDは、すでに一意の名前を持つものに、対応表を保存せずに安定したIDを付けたいときに使います。

v3よりv5を選んでください。MD5はより弱く、RFC 9562もv5を推奨しています。どちらも名前を隠す手段にはならず、名前を推測できる人は誰でも同じUUIDを計算できます。このページのv8は、RFC自身のv8の例と同じように、SHA-256を同じ方法で使います。

名前空間 + 名前 → v5RFC 9562 §5.5
  1. 名前空間6ba7b810-9dad-11d1-80b4-00c04fd430c8DNS · 16バイト
  2. 名前"www.example.com"UTF-8 · 15バイト
  3. SHA-1ダイジェスト、160ビット2ed6657de927468b55e12665a8aea6a22dee3e35先頭の128ビットを使用
  4. 結果のUUID2ed6657d-e927-568b-95e1-2665a8aea6a2バージョンの桁 4 → 5 · バリアントの桁 5 → 9
  • DNS6ba7b810…
  • URL6ba7b811…
  • OID6ba7b812…
  • X.5006ba7b814…
RFC 9562自身のv5の例:DNS名前空間のwww.example.comです。同じ名前空間と名前をハッシュすれば、どのコンピューターでも同じUUIDになります。

ULIDとUUID v7の比較(その他のIDも)

ULIDもUUID v7も48ビットのミリ秒タイムスタンプで始まり、時刻順にソートされます。違いは、ULIDが残りの80ビットをすべて乱数に使い、Base32の26文字で書かれるのに対し、v7はバージョンとバリアントに6ビットを使い、あらゆるUUID型の列やライブラリでそのまま使える点です。

データベース、ORM、APIがすでにUUIDに対応しているなら、v7を使えば新しい型を導入せずに時刻順が得られます。NanoIDなどの短いIDは長さを指定したランダムな文字列で、時刻も標準のレイアウトもありません。どのUUIDも短く書くことができ、Base64urlでは22文字、Base58では最大22文字です。

3つのID、いずれも128ビット縮尺どおり
UUID v7時刻、次にランダム
36文字時刻順にソート可能
ULID時刻、次にランダム
26文字時刻順にソート可能
UUID v4ランダムのみ
36文字順序なし
  • 1970年からのミリ秒
  • ランダム
  • バージョンとバリアント
UUID v7とULIDは、48ビットのミリ秒の時計を共有します。v7はバージョンとバリアントに6ビットを使い、ULIDは80ビットすべてを乱数に使います。v4はランダムのみで、Base64urlではどのUUIDも22文字です。

UUIDをトークンとして使っても安全?

いいえ。RFC 9562は、UUIDが推測しにくいと仮定してはならず、セキュリティ上のケイパビリティ、つまり持っているだけでアクセスが許可されるID(パスワードリセットのリンクやAPIキーなど)として使ってはならないとしています。

良いジェネレーターで作られたv4はランダムですが、v1、v6、v7は作成時刻を明かし、v3やv5は名前から再計算できます。秘密の値には、暗号論的乱数生成器で作った256ビットの乱数など、そのために作られたトークンを使い、リクエストのたびに権限をチェックしてください。アクセスを別途チェックしているなら、UUIDは公開IDとして問題なく使えます。

ID見た人が分かること秘密の値として
v1、v6作成時刻と、場合によってはネットワークカードのMACアドレス使えない
v7作成されたミリ秒使えない
v5、v3新しい情報はないが、名前を推測されると同じUUIDになる使えない
v4正常なジェネレーターなら、何も分からない使えない
256ビットのトークン何も分からない:秘密の値のために作られている使える
RFC 9562は、UUIDが推測しにくいと仮定したり、セキュリティ上のケイパビリティとして使ったりしないよう求めています。秘密の値には暗号論的乱数生成器で作ったトークンを使い、リクエストのたびにアクセスをチェックしてください。

UUID生成ツール:よくある質問

UUIDを生成・発行するには?

このページを開くと、ランダムなUUID v4がすぐにコピーできる状態で表示され、「新しいUUID」を押すと次のUUIDを作成します。v7を選べばUUID v7生成ツールとして使え、個数を指定すれば最大10,000個を一度に作成でき、波かっこやBase64urlなどの形式も選べます。コードでは、JavaScriptの crypto.randomUUID()、Pythonの uuid.uuid4()、C#の Guid.NewGuid() が、それぞれ1行でv4を作成します。

UUIDは何の略ですか?

Universally Unique Identifier(汎用一意識別子)の略です。919108f7-52d1-4320-9bac-f847db4148a8のように36文字で書かれる128ビットの値で、コンピューターが中央の登録機関なしにそれぞれ独立して作成しても、一意であると見なせます。RFC 9562で定義されており、Microsoftは同じ値をGUID(Globally Unique Identifier)と呼びます。

GUIDとUUIDは同じものですか?

実用上は同じです。128ビットもテキスト形式も同じで、Guid.NewGuid()は標準的なバージョン4のUUIDを作成します。違いは2点です。.NETは最初の3つのグループをリトルエンディアンで格納するため、生のバイト配列の順序が異なります。また、SQL Serverはuniqueidentifierの値を最後のグループから比較して並べます。GUIDを生成したいときは、このページをランダムなGUID生成ツールとして使ってください。コピーしたテキストはどちらの環境でも使えます。

どのUUIDバージョンを使うべきですか?

データベースのキーやソートするものには、バージョン7を使います。作成時刻で始まるため、インデックスがコンパクトに保たれます。IDから作成時刻を知られたくない場合はバージョン4、同じ名前を常に同じIDに対応させたい場合はバージョン5です。新しく作るものにv1は避けてください。RFC 9562は代わりにv7を推奨しており、v1には実際のMACアドレスが含まれることがあります。

2つのUUIDが同じになることはありますか?

ジェネレーターが正常なら、天文学的に小さな確率でしか起きません。v4はランダムな122ビットを持つため、約103兆個のUUIDで重複が1組起きる確率が10億分の1、確率が50%になるには約271京個が必要です。実際に起きる重複の原因は、計算上の確率ではなく、欠陥のあるジェネレーター、複製された仮想マシン、コピーされたデータです。

UUIDはデコードできますか?

部分的にはできます。どのUUIDからもバージョンとバリアントが分かります。v7からは作成されたミリ秒も、v1やv6からは100ナノ秒単位の時刻、クロックシーケンス、ノードIDが分かり、ノードIDが実際のMACアドレスの場合もあります。v4にはランダムビットしかなく、v3とv5には名前に戻せないハッシュが入っています。「デコードと検証」に貼り付けてお試しください。

UUIDの長さは何文字ですか?

128ビット、つまり16バイトです。テキストでは36文字で、16進数32桁とハイフン4つを8-4-4-4-12のグループに分けて書きます。ハイフンなしでは32文字、波かっこ付きでは38文字、urn:uuid:付きでは45文字、Base64urlでは22文字、10進数の整数では最大39桁です。可能であれば、テキストではなくネイティブのUUID型か16バイトで保存してください。

空のGUID(Nil UUID)とは何ですか?

128ビットすべてが0の値、00000000-0000-0000-0000-000000000000です。RFC 9562ではNil UUIDと呼ばれ、.NETのGuid.Emptyも同じ値で、IDが未設定であることを示すのによく使われます。RFC 9562は、すべてのビットが1のMax UUID、ffffffff-ffff-ffff-ffff-ffffffffffffも番兵値として定義しています(.NET 9ではGuid.AllBitsSet)。どちらもランダムではないため、実際のIDとしては使わないでください。

UUID v7はソートできますか?

はい。先頭の48ビットがミリ秒単位のUnix時間なので、v7のUUIDをテキストまたはバイト列としてソートすると、ミリ秒単位で作成時刻順に並びます。同じミリ秒内の順序はジェネレーター次第で、このツールはRFC 9562のセクション6.2のとおり、一括生成した値を厳密に増加させます。例外はSQL Serverのuniqueidentifierで、最後のグループから比較します。

UUIDをパスワードやアクセストークンとして使っても安全ですか?

いいえ。RFC 9562は、UUIDが推測しにくいと仮定したり、セキュリティ上のケイパビリティとして使ったりしないよう警告しています。時刻ベースのバージョンは作成時刻を明かし、名前ベースのものは再計算できます。秘密の値には暗号論的乱数生成器で作ったランダムなトークンを使い、UUIDはアクセスを別途チェックする公開IDとして扱ってください。パスワードには、パスワード生成ツールを使ってください。

ここで作成したUUIDはどこかに送信されますか?

いいえ。UUIDは、ブラウザーの暗号論的に安全な乱数生成器であるcrypto.getRandomValuesを使ってブラウザー内で作成され、貼り付けたUUIDもお使いの端末上でデコードされます。生成したものも貼り付けたものも、当サイトを含め誰にも送信されません。共有リンクには選んだ内容、つまりバージョン、個数、形式、v5の名前、またはデコーダーに貼り付けたUUIDだけが含まれるため、それらと同じつもりで共有してください。

足りないものはありますか?機能や新しいツールを提案する