The ASP.NET Repeater control is a very useful patten that minimizes code and allows you to use templates to represent repetitive data.

All of you are probably familiar with it and use it quite often.

Yesterday I had a big fight with the repeater control, and since most of the Internet (actually search engines for that matter) is filled with lots of data about the Repeater control and how to use it, I couldn’t find the answer I was looking for.

Apparently it was staring me right in the face.

The problem was that I needed to display a list of words with a comma separator and they should have looked like this:

word a, word b, word c, word d

but what I got was this:

word a , word b , word c , word d

An additional and unwanted extra space before the comma.

That code that I used in the ASPX file was this:



<% #Eval(“Text”) %>


<SeparatorTemplate>, </SeparatorTemplate>


All seems well, right? there is no space before the comma in the separator template, but there was when the whole thing was rendered.

The fix was quite stupid (and is quite fragile):



<% #Eval(“Text”) %></ItemTemplate>

<SeparatorTemplate>, </SeparatorTemplate>


The extra enter which placed the </ItemTemplate> element in a new line was the cause of this problem. That new line was translated in this case into a single space which made everything look weird.

It seem that the Repeater control (and possibly other template based ASP.NET controls) are sensitive to the ASPX formatting. They are not trimming the edges of content that resides inside the template ASPX element, thus making them susceptible for formatting weirdness.

The worst problem of all is that when you use Visual Studio’s auto formating (Ctrl-E, Ctrl-D by default, if I’m not mistaken) it will ruin the layout and you might end up with a Repeater that has an extra space even if you didn’t want it.

I can understand why the edges were not trimmed, so that you can and should be able to enter white spaces as part of your template, but Visual Studio itself when formatting a document to be more clearly read will mess things up and that is the true problem.

While this is not a “real” advanced .NET debugging issue and I didn’t use any cool tools to figure it out it annoying nonetheless 🙂

  • This has been an IE rendering bug for awhile. Check out websites like and many others that teach web standards and css methods for taming browser variances.

  • Papio,

    I don’t think this is an IE rendering bug since the additional whitespace is added in FireFox and Safari as well.

    It is most likely related to the way ASP.NET parses elements inside the ASPX file and output the additional space.

  • Tatter

    I’m having a very odd problem with repeaters myself, and it may or may not be related.

    When my databound repeaters are rendered, somehow extra characters are being added to the response output at random intervals. These extra characters are always an ASCII carriage return (0x0D), ASCII line feed (0x0A), and UTF-8 byte order mark (0xEF 0xBB 0xBF). This doesn’t just occur at the beginning or end of the repeater’s HTML output; it can randomly occur anywhere inside it as well, and causes controls in the repeater to stop working on occasion when the five-byte sequence occurs in a critical output tag, like a postback or anchor.

    Nobody else has even heard of this problem before. It occurs in the same project on multiple systems, and has not occurred yet in any other project. I figure I screwed up the project’s configuration settings somehow, but I have no clue just how, and neither does anyone else. Commenting out the globalization key in the web.config (the default generated one, with request and response encodings set to “utf-8”) does not fix the problem, and I’ve tried manually setting the page’s encodings to every possible setting that doesn’t trigger a compiler error, as well as leaving them set to the defaults, and nothing seems to solve this problem.

    Has anyone, anywhere, ever heard of this?

  • Tatter,

    This seems like a very weird problem indeed. The problem I had was deterministic in the sense that the whitespaces always appeared in the same place.

    Is there any chance you have a filter on your response that it doing something? Have you tried to use Fiddler or Ethereal/Wireshark to make sure that this is actually going out of the server?

    Perhaps you can write a filter that will dump things before they go out to make sure that this is indeed happening in the server.

    In the worst case a Response Filter might even remove this but it will cost in performance.

    Other than that, I have run out of ideas. If I’ll think of something I’ll post about it.

  • Your problem was not with .NET, rather, it was with the way that web browsers render whitespace. The standard interpretation of HTML reduces all contiguous whitespace to a single space. If you had taken the time to look at your HTML, you would have noticed that you were placing a newline both before and after your words. That is to say, the contents inside your Item Template tags is repeated verbatim; the best coding practices would have your opening and closing tags on the same line, to ensure that your elements come out exactly as you intend.

  • I know this is a browser issue, but since it runs in a templated environment (ASP.NET) inside non HTML tags I would have expected Microsoft to take that into account.

    After all, the process the ASPX page which when used with server side controls is not the direct HTML output.

    I know it’s a silly rant, but it seems I’m not the only one thinking that it should work that way 🙂

    Oh well, ce la vie.

  • OH! Thanks for this article! This problem… it has been killing me whole morning, and nobody on the internet seems to know this but you. And now me too:)
    Thanks again!

  • Leon, you are most welcome 🙂 I’m glad I could help.

  • Jeanie Mellem

    I had an extra line after each item in the repeater and your solution fixed the problem. Don’t know that I would have thought of that.

  • Praveen Namburi

    I seem to be having the same problem and removed the extra enter but that doesn’t seem to resolve the problem. I still see the extra characters. The only difference is I am using a DataList and did not use the seperator template.

    Let me know if you guys have any ides.


  • Jay

    Thanks for posting this. Saved me a lot of time!

  • Ritu

    Thanks for the posting.Its really a very silly thing but ur posting helped me in saving my time and energy.

  • Using a lot of custom templates I always run into this issue – its sooo annoying! especially long custom templates are not suitable to have on one line.

    Do let me know if anyone has a “fix” for this.


  • Fascinator

    Thank you for resolving this issue and informing internet community.

  • Carlos Villegas