You don't need a parser, just a lexical scanner will work, tokenizing the text to a sequence of tokens.

Alternatively, you can use regular expressions, or even look for "[" in the text 'manually', but that seems like more work at first sight.

If the syntax keeps as simple as your example shows then you wont even need a tokenizer just a stated reader something that does

while text < end
{
   if text is [
   {
        property : string
        value : string

        while text not = or ]
            property += text
        while text not ]
            value += text

        switch property
            case color: set color to 'value'
   }
   else
   {
      output : string

      while text not [ and < end
         output += text

      print output
   }
}

(pseudo code)

Edit

Even if you decide to use a tokenizer/parser just avoid using something like ANTLR because it produces to heavy code. Then you should define your rules by hand it is simpler as you might think even for such syntax schemas as C++

Is there a simple and fast tokenizer that suits my needs? Or just should I rather write one?

I see, tokenizer not a parser then :) Is there a simple and fast tokenizer that suits my needs? Or just should I rather write one?

lex & yacc are the defacto-standard parsing tools, where 'lex' is the scanner generator (builds a sub-routine to convert text to tokens), and 'yacc' is the parser generator (builds a routine to convert the token stream to tree according to grammar production rules). Gnu versions of this are flex & bison. These tools are also used in production.

While they are designed to be used together, they are separate tools, and you can also write a manual scanner (quite easy usually, although there is the problem of longest match you must handle), and feed its output to the generated parser. The other way around is also possible, but since a parser is usually non-trivial or too big to write by hand, you almost never see this.

Simplest lex spec (untested, and my lex is a bit rusty):

\[ *color *= *[a-z]+ *\]        { /* return color as identifier */ }
\[ *color *= *[0-9]+ *, *[0-9]+ *, *[0-9]+ *\]   { /* return color as number */ }
\[ *img *= *[^] ]+ *\]     { /* return img link */ }
.   { /* return normal character */ }

This recognizes the three [ ] constructs, and "text" for anything else (note the dot at the start of the line). The disadvantage here it only splits the strem into separate cases, you'll still have to extract the color or link yourself afterwards. This can be improved by recognizing "[color=" for example, and then jump to a color value recognition state, where you recognize the value. Similar approach works for image links too.

boost::spirit and lex/yacc are massive overkill for a simple string chunking problem

In particular, I didn't advocate for using yacc, which is indeed overkill for the problem.