# Should we profile CIDs?

**URL:** https://discuss.ipfs.tech/t/should-we-profile-cids/18507
**Category:** Protocol
**Created:** [September 16, 2024, 9:07am UTC](https://discuss.ipfs.tech/t/should-we-profile-cids/18507 "2024-09-16T09:07:36Z")
**Posts on this page:** 1
**Showing post:** 13

<div class="post-metadata">

### Author: ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)
#### Post date: [September 16, 2024, 4:13pm UTC](https://discuss.ipfs.tech/t/should-we-profile-cids/18507/13 "2024-09-16T16:13:18Z")

</div>

> [@willscott](#):
>
> it’ll look like
> 
> ```auto
> 42(h'000181E2039220200C7C257C5EA6BBA17053362...')
> 
> ```
> 
> None of the ipfs tooling allows me to take a hex-of-binary representation of a cid today and get back the actual cid

That’s not really true, see [Go Playground - The Go Programming Language](https://go.dev/play/p/MTzyQyLgmXP).

What you seem to be encountering is the result of the creators of dag-cbor choosing to encode CIDs not in their binary form, but in their string form but with an identity multibase. Most people’s use of tooling is around the binary form, or a human-readable string form so the use of the identity multibase can be pretty confusing. In the hex case if you replace the first 00 with an F most other tooling works fine as well.

I’ve yet to find someone using the identity multibase in a way I found natural, but perhaps that’s just me.

---

_[View the full topic](https://discuss.ipfs.tech/t/should-we-profile-cids/18507)._