Subscribe to
NSLog(); Header Image

Safari’s Table-Copying Behavior

It's long pissed me off, but I've never had the time to write about it. I don't so much have the time now, but the "pissiness" has reached critical mass, so to speak.

Safari's table-copying sucks. Here, go ahead, try it out:

Pos Player Today Thru Total
1 DiMarco -1 6 -5
T2 Donald -5 7 -4
T2 Allenby -1 8 -4
T4 Moore -3 10 -3
T4 Woods -5 14 -3

I would expect Safari to copy that with tabs and line breaks so that, when pasted, the result might look something like a table (bear in mind I have no idea how tabs in <pre> appear in your browser, but it should look fine):

Pos	Player	Today	Thru	Total
1	DiMarco	-1	6	-5
T2	Donald	-5	7	-4
T2	Allenby	-1	8	-4
T4	Moore	-3	10	-3
T4	Woods	-5	14	-3

What does it do instead?







Yeah, that's real frickin' helpful. Copied table text such as this, which I commonly use to create leaderboards at The Sand Trap, go through a BBEdit cycle that looks like this:

  1. Turn off soft wrapping (on by my default).
  2. Find '\r\r', replace with '@'
  3. Find '\r', replace with about ten spaces.
  4. Find '@', replace with '\r'
  5. Make the columns line up (column selection/deletion is only available when soft wrapping is disabled).

It's a far more tedious process than it need be, and Safari's copy results hardly represent the look and feel of a table. This isn't hard, and I remain hopeful that it's fixed. Soon!

P.S. Leaderboards at The Sand Trap copy properly because they're just <pre> text, not tables like on

25 Responses to "Safari’s Table-Copying Behavior"

  1. If you copy the table, and paste it into a 6x6 table in Pages (should also work in Word), then export as plain text, the resulting file could be put in a <pre> tag.

    I know that doesn't solve Safari's problem, but I thought I would point it out. For what it's worth, this is what I got with Firefox:

    Pos Player Today Thru Total

    1 DiMarco -1 6 -5

    T2 Donald -5 7 -4

    T2 Allenby -1 8 -4

    T4 Moore -3 10 -3

    T4 Woods -5 14 -3

  2. When I copied that from Firefox and pasted it into a text editor (TextWrangler or TextEdit) it didn't look right (those editors are probably set to use a certain size for tabs). It looks right in the above post though (as well as in pico). I only posted it because I thought Firefox wasn't doing something right.

  3. I realize Firefox does it properly. But Safari - an app used by milllions (including me) does not. Which is why this is called "Safari's Table-Copying Behavior."

    And Bruce, FWIW, pasting into a table in Pages does not work.

  4. What's the Radar number for this?

  5. It's my understanding that Radar bug #s are confidential and, as a developer who's signed an NDA, items that I should not publicly divulge.

  6. For what it's wortH: the table renders perfectly for me in OmniWeb and also in Safari!

  7. Sorry, I'm an idiot -- trying to do too many things at once. Yes, Safari renders the table fine, but you were talking about copying. Safari indeed has the problem you identify, and so does OmniWeb, which is not surprising since OmniWeb uses the same rendering engine.

  8. "pasting into a table in Pages does not work"

    I should have been more clear. You have to select the cells you want to paste into. In this example, if you selected all the cells (not the table itself) in the 6x6 table you made, it would paste each "line" into a cell.

  9. I can't imagine what could be confidential about a Radar number for a bug you filed. What you wrote for the bug report is confidential if it's NDA'd software or if it's confidential for your company, but the bug number is of no value to anyone other than you and anyone at Apple.

    Developers post bug numbers to Apple mailing lists all the time, even adding an 'rdar://' in front so folks at Apple can click on them. It's very helpful.

  10. I have used the ms-word work-around for years but my "pissiness" for being forced to do so has reached similar critical levels. Thanks for reporting this, I thought I was alone in this so far...

  11. This has long been an annoyance for me too. However, the not bad thing is that the string is regularly formatted and can easily be changed to something useful with regular expressions. Here are two BBEdit Text Factories; one changes the Safari copied table string into tab delimited and the other changes it into an html table. I hope they make life a little easier for folks.

  12. There's a Safari table I have to copy every month (for residuals). I had no idea that Firefox did it properly, so I ended up writing a Python script to re-format it. And I'm not a coder, so I'm sure this could be much prettier.


    import sys

    temp_list = []

    output_list = []

    for line in sys.stdin:

    if line == "\n":


    temp_list = []



    for item in output_list:

    print "\t".join(item)

  13. Thanks Adolph. That actually helps me a bit. Saves me from writing my own scripts/factories.

  14. included in os 10.3.9 is safari 1.3 which fixes the table copying behaviour.

  15. Uh, no, it does not fix it.

  16. it worked for me... copying and pasting the table from the top of this page to text edit and text wrangler...

    i'll try again, when i get back home.

  17. you're right.

    maybe i had firefox data in the clipboard and when i tried copying in safari i was hitting the wrong key. (most likely cmd+v, but i was definitely in safari).

    my bad.

  18. I continued thinking about this topic and wrote a cleaner shell script for the Safari table to tabs problem:


    pbpaste | perl -p -e 's/(\r|\n)/\r\t/gi' | perl -p -e 's/\r\t\r\t/\r/gi' | perl -p -e 's/\r\t/\t/gi' | pbcopy

    I'm certain that someone better at Perl can rewrite this to be shorter. I wrote this one because I was copying Safari tables into a Windows XP device over RDC and pasting into BBEdit, executing the text factory, and copy/pasting into RDC, which was a pain. I have plugged the script into Quicksilver, so that the workflow is copy, QS command, then paste.

  19. Did Safari 2.0 (412.2.2 - the one you get with Security Update 2005-007) break table-copying behavior for anyone else, or just me? I used this page as a test. I pasted into BBEdit (8.2.3). Safari had been working properly for...

  20. This pisses me off too. I just sent a message to fix it to Apple via the Safari->Report Bug to Apple... menu item - though I'm pretty sure they already know about it. I will start using Firefox if they don't fix this soon.

  21. We also run a golf website and copy scores weekly from every tour website. We have scripts in BBEdit that make them all in the same format eg Position +/- par Name etc etc.

    Camino, Mozilla and Firefox all do as expected and copy from table with tabs and line breaks - Safari does not and is very annoying hence we use Camino as our day to day browser. Faster than them all and copies tables correctly.

    End result is do not use Safari or switch to Camino etc when you ahve to copy a table. Will save you a shedload of time.

  22. Sorry to comment on a 3-year-old post, but I came across this as I was googling about the same issue (that STILL exists in 2008!), and then I wrote an AppleScript to fix it. I know, I should have just used Firefox, but I like Safari's speed.

    At any rate, the following script (pasted into Script Editor, and saved as an Application) will clean up whatever table Safari put on the clipboard, and make it work better with Mac apps that accept tab-delimited text (such as Numbers, Excel, etc.):

    set mydata to get the clipboard as text
    set AppleScript's text item delimiters to {(ASCII character 13) as text}
    set mylines to text items of mydata
    set AppleScript's text item delimiters to {return}
    set the clipboard to mylines as text
    set AppleScript's text item delimiters to {""}

  23. Erik,
    A few minutes ago I posted a comment on this 3-year-old blog entry, and now I realize I may have misspoken in my comment. But it's in the moderation queue, so I can't see it to know for sure. The script I attempted to post still works, but my description of the script was faulty. I claimed ASCII 13 was a Unix-style line break, which of course it's not--it's a Mac-style line break. So the script apparently switches Mac-style line breaks out for Mac-style linebreaks, which shouldn't really affect anything--but it somehow kicks things into working. (You can maybe understand how I became confused.)

  24. Last word on the subject (I promise)... the applescript quoted before can be shortened to:

    set the clipboard to (the clipboard as text)

    what it's doing is simply stripping out the Rich Text representation that Safari is putting the clipboard (which screws up the tabular format), leaving only the plain text representation that Numbers & other apps are more likely to handle correctly.

  25. You're a champion Lowell - we run a golf site too and I have had to keep FF open all the time just to do scores as Safari is so much quicker I use that the rest of the time.

    The script works fantastically!

    Unfortunately I still need FF when doing CSS - WebDev can't be beaten by WebKit's inspector yet.....