What are the benefits to using string datatypes over bytes32 to represent text data. It seems my contract runs into an out of gas exception when I switch the data structures from bytes32 to string.


Why string instead of bytes32?

Use string for arbitrary-length string (UTF-8) data that's longer than 32 bytes. Frontends can decode a long string easier using methods like web3.toAscii or UTF-8 (when issues are fixed), instead of implementing the logic of UTF-8 decoding a series of bytes32.

From Solidity docs:

As a rule of thumb, use bytes for arbitrary-length raw byte data and string for arbitrary-length string (UTF-8) data. If you can limit the length to a certain number of bytes, always use one of bytes1 to bytes32 because they are much cheaper.

String literals may also be helpful or convenient:

String literals are written with either double or single-quotes ("foo" or 'bar')...

String literals support escape characters, such as \n, \xNN and \uNNNN. \xNN takes a hex value and inserts the appropriate byte, while \uNNNN takes a Unicode codepoint and inserts an UTF-8 sequence.

Why bytes32 instead of string?

Answered in Why do Solidity examples use bytes32 type instead of string?

bytes32 uses less gas because it fits in a single word of the EVM, and string is a dynamically sized-type which has current limitations in Solidity (such as can't be returned from a function to a contract).

  • I am not sure if I understood the last sentence - string return types work in current Solidity compiler. Jan 21 '17 at 10:10
  • 2
    @MikkoOhtamaa Emphasis is to a contract: I don't think ethereum.stackexchange.com/a/3788/42 is supported yet.
    – eth
    Jan 21 '17 at 13:53
  • Ok so if you have a controlling contract and it's accessing data from another contract which is returning text that is longer than 32 bytes, you would need to return it in a bytes32 array?
    – ethereal
    Jan 22 '17 at 17:54
  • @ethereal Sounds right, give a size to the array like bytes32[3]. There may be assembly ways to get the size of the data being returned and avoiding a hardcoded size, for example the contracts in github.com/ownage-ltd/ether-router
    – eth
    Jan 25 '17 at 0:50
  • 1
    If a contract cannot access another contract's string variables, then what can? Can web3? What if I want to store a list or array of 60-character strings, but I will need to access them from another contract or program, how do I do it?
    – Curt
    Aug 4 '17 at 1:59

Like the other post said, you only want to use strings for dynamically allocated data, otherwise Byte32 is going to perform better. Bytes32 is also going to be better in gas. If you want to play around with it, I built a little fiddle of it https://ethfiddle.com/70ipaEIFdk

Byte used 21465 gas

String used 21897 gas

pragma solidity ^0.4.18;

contract SampleOverflow {
  string constant statictext = "HelloStackOverFlow";
  bytes32 constant byteText = "HelloStackOverFlow";
  function  getString() payable public  returns(string){
    return statictext;

  function  getByte() payable public returns(bytes32){
    return byteText;

Get Byte enter image description here

Get String enter image description here https://ethfiddle.com/70ipaEIFdk

  • that fiddle doesn't work. I think it's to do with the escaped double quotes. I tried removing escape caharacters but eth fiddle didnt liek that either.. Here's your example working ethfiddle.com/SeXTGt-AWi Dec 30 '17 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.