Take the 2-minute tour ×

Is a GUID unique 100% of the time?

Will it stay unique over multiple threads?

share|improve this question
No, not 100%... Just 99,999999999999999999999999999999999999999999999999999999999999999999999999999% ;) –  JohannesH Nov 18 '09 at 10:37
First of all, a GUID is not infinite, which means that for the literal meaning of "100% of the time", would mean that no matter how long you keep generating GUID's, they would always be unique. This is not the case. Also, since the original implementation, where the network card unique serial/id/MAC was used to produce a portion of the key is no longer used, for various reasons, a GUID is not really globally unique any more. It is, however, locally unique. In other words, if you keep generating GUIDs on a single machine, you will not get duplicates. –  Lasse V. Karlsen Jan 29 '10 at 23:55
@JohannesH I think you missed a 9. –  ojrac Feb 3 '10 at 23:46
@ojrac I just choose to round down... :P –  JohannesH Feb 4 '10 at 9:07
Every time I generate GUID I feel like I'm stealing one from the Universe. Sometimes I think about evil people who generate much more GUIDs than they need and those wasted GUIDs are so lonely not being used or generated again... –  asavartsov Feb 9 '13 at 21:40
show 4 more comments

14 Answers

up vote 146 down vote accepted


From Wikipedia.

share|improve this answer
Wouldn't they be called a UUID, then? ;) –  Arafangion May 8 '09 at 6:23
A GUID is microsoft's specifica implementation of the UUID standard. So, it's both. Globally unique ID vs Universally unique ID. –  Adam Davis May 8 '09 at 11:49
Technically, it is not 2^128, because in a v4 GUID, you have one hex digit that will always be a 4 (effectively removing 4 bits), and two bits further on are also reserved. However, 2^122 valid V4 GUIDs still leaves about 5x10^36, which will do for me. and for you too. Each star will have to accept just about 1.1x10^14 GUIDs apiece. –  Andrew Shelansky Oct 8 '10 at 18:53
If you're like me, then you'll want to know that 2^128 written out is approximately: 34,028,236,692,093,846,346,337,460,743,177,000,000. Statistically, if you calculated 1000 GUIDs every second, it would still take trillions of years to get a duplicate. –  TheAdamGaskins Jul 24 '12 at 4:01
@TheAdamGaskins Challenge accepted. –  asavartsov Feb 9 '13 at 21:36
show 8 more comments

The simple answer is yes.

Raymond Chen wrote a great article on GUIDs and why substrings of GUIDs are not guaranteed unique. The article goes in to some depth as to the way GUIDs are generated and the data they use to ensure uniqueness, which should go to some length in explaining why they are :-)

share|improve this answer
I think Chen's article is referring to V1 of the GUID generation algorithm, which uses a MAC address & timestamp -- the current V4 uses a pseudo-random number instead: en.wikipedia.org/wiki/Globally_Unique_Identifier#Algorithm –  Barrett Jul 7 '09 at 14:37
add comment

Yes, a GUID should always be unique. It is based on both hardware and time, plus a few extra bits to make sure it's unique. I'm sure it's theoretically possible to end up with two identical ones, but extremely unlikely in a real-world scenario.

Here's a great article by Raymond Chen on Guids:


share|improve this answer
add comment

As a side note, I was playing around with Volume GUIDs in Windows XP. This is a very obscure partition layout with three disks and fourteen volumes.

\\?\Volume{23005604-eb1b-11de-85ba-806d6172696f}\ (F:)
\\?\Volume{23005605-eb1b-11de-85ba-806d6172696f}\ (G:)
\\?\Volume{23005606-eb1b-11de-85ba-806d6172696f}\ (H:)
\\?\Volume{23005607-eb1b-11de-85ba-806d6172696f}\ (J:)
\\?\Volume{23005608-eb1b-11de-85ba-806d6172696f}\ (D:)
\\?\Volume{23005609-eb1b-11de-85ba-806d6172696f}\ (P:)
\\?\Volume{2300560b-eb1b-11de-85ba-806d6172696f}\ (K:)
\\?\Volume{2300560c-eb1b-11de-85ba-806d6172696f}\ (L:)
\\?\Volume{2300560d-eb1b-11de-85ba-806d6172696f}\ (M:)
\\?\Volume{2300560e-eb1b-11de-85ba-806d6172696f}\ (N:)
\\?\Volume{2300560f-eb1b-11de-85ba-806d6172696f}\ (O:)
\\?\Volume{23005610-eb1b-11de-85ba-806d6172696f}\ (E:)
\\?\Volume{23005611-eb1b-11de-85ba-806d6172696f}\ (R:)
                                     | | | | |
                                     | | | | +-- o
                                     | | | +---- i
                                     | | +------ r
                                     | +-------- a
                                     +---------- m

It's not that the GUIDs are very similar but the fact that all GUIDs have the string "mario" in them. Is that a coincidence or is there an explanation behind this?

Now, when googling for part 4 in the GUID I found approx 125.000 hits with volume GUIDs.

Conclusion: When it comes to Volume GUIDs they aren't as unique as other GUIDs.

share|improve this answer
Remember that Super Mario Bros 3 ad from the 80's? All those people yelling "Mario! Mario! Mario!" around the world upset the randomness of the universe a bit. –  MGOwen Apr 29 '10 at 5:05
If you manually un-install Office 2010 with msiexec, it lists all the MSI GUID's of the office program. They all spell 0FF1CE. Seems like Microsoft have a fairly... loose... interpretation of how to generate a GUID ;) –  Mark Henderson Apr 30 '11 at 3:21
These partition GUIDs were all created together at 2009-12-17 @ 2:47:45 PM UTC. They are unique to your machine, but putting "mario" as the node identifier is incorrect - it means they're not RFC-4122-compliant. Likewise, the 0FF1CE GUIDs fall under the "NCS backwards compatibility" section of RFC-4122, but it's unlikely that Microsoft is following the NCS rules for those values. –  Stephen Cleary Sep 3 '11 at 2:44
add comment

It should not happen. However, when .NET is under a heavy load, it is possible to get duplicate guids. I have two different web servers using two different sql servers. I went to merge the data and found I had 15 million guids and 7 duplicates.

share|improve this answer
How is this possible on two different machines? I thought part of the GUID was the machine name? (not arguing... just asking) –  John Cruz Sep 6 '10 at 21:47
This would only be true for v1 guids which uses MAC addresses (not machine name) as part of the GUID generation. The v4, which is the de facto STD no longer uses Mac addresses but a pseudo random number. –  Xander Feb 10 '11 at 13:52
Guid.NewGuid always generates v4 GUIDs (and always has). Tim must have had extremely poor entropy sources. –  Stephen Cleary Sep 3 '11 at 2:45
add comment

Guids are statistically unique. The odds of two different clients generating the same Guid are infinitesimally small (assuming no bugs in the Guid generating code). You may as well worry about your processor glitching due to a cosmic ray and deciding that 2+2=5 today.

Multiple threads allocating new guids will get unique values, but you should get that the function you are calling is thread safe. Which environment is this in?

share|improve this answer
add comment

Theoretically, no, they are not unique. It's possible to generate an identical guid over and over. However, the chances of it happening are so low that you can assume they are unique.

I've read before that the chances are so low that you really should stress about something else--like your server spontaneously combusting or other bugs in your code. That is, assume it's unique and don't build in any code to "catch" duplicates--spend your time on something more likely to happen (i.e. anything else).

I made an attempt to describe the usefulness of GUIDs to my blog audience (non-technical family memebers). From there (via Wikipedia), the odds of generating a duplicate GUID:

  • 1 in 2^128
  • 1 in 340 undecillion (don’t worry, undecillion is not on the quiz)
  • 1 in 3.4 × 10^38
  • 1 in 340,000,000,000,000,000,000,000,000,000,000,000,000
share|improve this answer
add comment

Eric Lippert has written a very interesting series of articles about GUIDs.


share|improve this answer
...and he continues in the next paragraph: "But that's looking for a collision with a specific GUID. [...] So if we put those billion PCs to work generating 122-bits-of-randomness GUIDs, the probability that two of them somewhere in there would collide gets really high after about 2^61 GUIDs are generated. Since we're assuming that about 2^30 machines are doing 2^20 GUIDs per second, we'd expect a collision after about 2^11 seconds, which is about an hour." (And finally he explains that, of course, not that many GUIDs are generated.) –  Arjan Oct 26 '13 at 10:08
add comment

If your system clock is set properly and hasn't wrapped around, and if your NIC has its own MAC (i.e. you haven't set a custom MAC) and your NIC vendor has not been recycling MACs (which they are not supposed to do but which has been known to occur), and if your system's GUID generation function is properly implemented, then your system will never generate duplicate GUIDs.

If everyone on earth who is generating GUIDs follows those rules then your GUIDs will be globally unique.

In practice, the number of people who break the rules is low, and their GUIDs are unlikely to "escape". Conflicts are statistically improbable.

share|improve this answer
This would only be true for v1 guids. The v4, which is the de facto STD no longer uses Mac addresses but a pseudo random number. –  Pita.O Jun 17 '10 at 8:57
"then your system will never generate duplicate GUIDs" Even if all the rules were followed for a v1 guid as you say, your system could still generate duplicates. You are more correct at the bottom when you state "Conflicts are statistically improbable." –  Nick Meldrum Feb 18 '11 at 8:41
add comment



share|improve this answer
add comment

Is a GUID unique 100% of the time?

Not guaranteed, since there are several ways of generating one. However, you can try to calculate the chance of creating two GUIDs that are identical and you get the idea: a GUID has 128 bits, hence, there are 2128 distinct GUIDs – much more than there are stars in the known universe. Read the wikipedia article for more details.

share|improve this answer
add comment

I experienced a duplicate GUID.

I use the Neat Receipts desktop scanner and it comes with proprietary database software. The software has a sync to cloud feature, and I kept getting an error upon syncing. A gander at the logs revealed the awesome line: "errors":[{"code":1,"message":"creator_guid: is already taken","guid":"C83E5734-D77A-4B09-B8C1-9623CAC7B167"}]}

I was a bit in disbelief, but surely enough, when I found a way into my local neatworks database and deleted the record containing that GUID, the error stopped occurring.

So to answer your question with anecdotal evidence, no. A duplicate is possible. But it is likely that the reason it happened wasn't due to chance, but due to standard practice not being adhered to in some way. (I am just not that lucky) However, I cannot say for sure. It isn't my software.

Their customer support was EXTREMELY courteous and helpful, but they must have never encountered this issue before because after 3+ hours on the phone with them, they didn't find the solution. (FWIW, I am very impressed by Neat, and this glitch, however frustrating, didn't change my opinion of their product.)

share|improve this answer
Don't believe you got a duplicate. There was probably something else involved, like number was not truly random or problem in the sync process, or system tried to record twice, etc. A software issue is much more likely than you getting a duplicate GUID. –  orad Sep 19 '13 at 21:22
add comment

I am late to answer here, but very curious to answer and the percentage on how often, it would.:)

it is not just 99,999999999999999999999999999999999999999999999999999999999999999999999999999%.

I ran through with following code, and found that from 120 every 7-8 Guid.NewGuid() got duplicated.

static void Main(string[] args)
                Thread thrd = new Thread(GetGuid);


        private static DataTable dt = new DataTable();
        private static void GetGuid()

enter image description here

share|improve this answer
add comment

GUID algorithms are usually implemented according to the v4 GUID specification, which is essentially a pseudo-random string. Sadly, these fall into the category of "likely non-unique", from Wikipedia (I don't know why so many people ignore this bit): "... other GUID versions have different uniqueness properties and probabilities, ranging from guaranteed uniqueness to likely non-uniqueness."

The pseudo-random properties of V8's JavaScript Math.random() are TERRIBLE at uniqueness, with collisions often coming after only a few thousand iterations, but V8 isn't the only culprit. I've seen real-world GUID collisions using both PHP and Ruby implementations of v4 GUIDs.

Because it's becoming more and more common to scale ID generation across multiple clients, and clusters of servers, entropy takes a big hit -- the chances of the same random seed being used to generate an ID escalate (time is often used as a random seed in pseudo-random generators), and GUID collisions escalate from "likely non-unique" to "very likely to cause lots of trouble".

To solve this problem, I set out to create an ID algorithm that could scale safely, and make better guarantees against collision. It does so by using the timestamp, an in-memory client counter, client fingerprint, and random characters. The combination of factors creates an additive complexity that is particularly resistant to collision, even if you scale it across a number of hosts:


share|improve this answer
add comment

Your Answer


