<p>I would store the CIDv0 in the metadata. You should be able to convert from v1 to v0 if it's using v1 protocol buffer codec.</p>
<pre><code># If this outputs &quot;protobuf&quot; we can be reasonably certain we can convert
ipfs cid format -f &quot;%c&quot; -b base58btc bafybeiccuppnh2nh54jtubqo2jjmngzlnnmliejjq3xlswxzh24et2llu4
# Convert our CIDv1 to CIDv0 (returns &quot;QmSpnYb3romJejsUqhRepYr6GBwuKUFj1kqrhtk1z2Hn8E&quot;)
ipfs cid format -f &quot;%M&quot; -b base58btc bafybeiccuppnh2nh54jtubqo2jjmngzlnnmliejjq3xlswxzh24et2llu4
</code></pre>
<p>Source: <a href="https://discuss.ipfs.io/t/make-cidv0-from-cidv1-using-cid-ipfs-io/10647/2" rel="nofollow noreferrer">https://discuss.ipfs.io/t/make-cidv0-from-cidv1-using-cid-ipfs-io/10647/2</a></p>

CC BY-SA 4.0
2021-09-03T01:51:10.830Z
Thanks for the comment - I'll see what I can do :-)
Braden
CC BY-SA 4.0
2021-10-02T12:56:23.760Z
Storing the longer image url as an array is also in-line with the CIP standard. If you use CIDv1 and store it as an ipfs url split in two, it should work and is supported by pool.pm and other NFT viewers out there.
Andrew Westberg - BCSH
CC BY-SA 4.0
2021-11-27T17:02:50.223Z
@AndrewWestberg-BCSH can you elaborate on this pls? how is this done?
rx2347
CC BY-SA 4.0
2021-11-30T22:58:44.637Z
@rx2347 To store it as an array, just do

```
"image": [ "first part of the url", "second part of the url"]
```
Andrew Westberg - BCSH
CC BY-SA 4.0
2021-11-30T23:07:46.450Z
@AndrewWestberg-BCSH so I just split the url string at a random character? thats so weird...
rx2347
CC BY-SA 4.0
2021-12-03T16:50:05.230Z
@rx2347 as long as each part is less than 64 chars, anybody implementing the NFT metadata spec just concatenates them together.
Andrew Westberg - BCSH
CC BY-SA 4.0
2021-08-31T13:33:51.207Z
2021-08-31T13:33:51.207Z
Andrew Westberg - BCSH
<p>I'm currently setting up my minting software and noticed I get the error when assigning a CIDv1 hash as the image (CIDv0 works fine - it just fits)&quot;Text string metadata value must consist of at most 64 UTF8 bytes&quot;</p>
<p>I also noticed that someone got around this by splitting it up into a list of less than 64 bytes each.</p>
<p>eg.</p>
<p>{...image: [ &quot;lessthan64string-0&quot;, &quot;lessthan64string-1&quot;, &quot;lessthan64string-2&quot;, &quot;lessthan64string-3&quot; ]...}</p>
<p>= lessthan64string-0lessthan64string-1lessthan64string-2lessthan64string-3</p>
<p>This seems very off standard for a NFT or am I wrong. Obviously you can recreate the string by joining, but I wouldn't think the chances of market places doing that is big.</p>
<p>I've had a look at - <a href="https://github.com/cardano-foundation/CIPs/pull/85" rel="noreferrer">https://github.com/cardano-foundation/CIPs/pull/85</a>, but I'm not sure about it.</p>
<p>If anyone could point me the the direction of what is the proper way to di this - It would be muchly appreciated</p>
<p>Thanks for your time</p>
<p>FYI: the reason for the CIDv1 is I am using <a href="https://nft.storage/" rel="noreferrer">https://nft.storage/</a> (as well as pinata) and I want the 2 hashes to match for longevity of the NFT for the images and they seem to only support CIDv1 - and it's going to have to be supported at some stage. The filecoin (nft.storage) one will be used as a backup</p>

<cardano-cli><nft><metadata>
Metadata value limits (64 UTF bytes) - Use Arrays ? NFT image question
# Metadata value limits (64 UTF bytes) - Use Arrays ? NFT image question

(Asked by: username_0 on 2021-07-24)

I'm currently setting up my minting software and noticed I get the error when assigning a CIDv1 hash as the image (CIDv0 works fine - it just fits)"Text string metadata value must consist of at most 64 UTF8 bytes"

I also noticed that someone got around this by splitting it up into a list of less than 64 bytes each.

eg.

{...image: [ "lessthan64string-0", "lessthan64string-1", "lessthan64string-2", "lessthan64string-3" ]...}

= lessthan64string-0lessthan64string-1lessthan64string-2lessthan64string-3

This seems very off standard for a NFT or am I wrong. Obviously you can recreate the string by joining, but I wouldn't think the chances of market places doing that is big.

I've had a look at - <https://github.com/cardano-foundation/CIPs/pull/85>, but I'm not sure about it.

If anyone could point me the the direction of what is the proper way to di this - It would be muchly appreciated

Thanks for your time

FYI: the reason for the CIDv1 is I am using <https://nft.storage/> (as well as pinata) and I want the 2 hashes to match for longevity of the NFT for the images and they seem to only support CIDv1 - and it's going to have to be supported at some stage. The filecoin (nft.storage) one will be used as a backup

**Tags:** cardano-cli, nft, metadata

---

## 1 answers

### Answer by username_1 on 2021-08-31. Score: 1

I would store the CIDv0 in the metadata. You should be able to convert from v1 to v0 if it's using v1 protocol buffer codec.
# If this outputs "protobuf" we can be reasonably certain we can convert
ipfs cid format -f "%c" -b base58btc bafybeiccuppnh2nh54jtubqo2jjmngzlnnmliejjq3xlswxzh24et2llu4
# Convert our CIDv1 to CIDv0 (returns "QmSpnYb3romJejsUqhRepYr6GBwuKUFj1kqrhtk1z2Hn8E")
ipfs cid format -f "%M" -b base58btc bafybeiccuppnh2nh54jtubqo2jjmngzlnnmliejjq3xlswxzh24et2llu4

Source: https://discuss.ipfs.io/t/make-cidv0-from-cidv1-using-cid-ipfs-io/10647/2

> **Comments:**
> **username_0**: Thanks for the comment - I'll see what I can do :-)  
> **username_1**: Storing the longer image url as an array is also in-line with the CIP standard. If you use CIDv1 and store it as an ipfs url split in two, it should work and is supported by pool.pm and other NFT viewers out there.  
> **username_2**: @AndrewWestberg-BCSH can you elaborate on this pls? how is this done?  
> **username_1**: @rx2347 To store it as an array, just do  ``` "image": [ "first part of the url", "second part of the url"] ```  
> **username_2**: @AndrewWestberg-BCSH so I just split the url string at a random character? thats so weird...  
> **username_1**: @rx2347 as long as each part is less than 64 chars, anybody implementing the NFT metadata spec just concatenates them together.  

---

